Security and Access Control
How access to AR data is controlled. Because Quick Receivable runs inside your Salesforce org, it works within the security model you already have.
This page needs verification before publishing. Security documentation is the one place where an unverified statement causes real damage, both in enterprise reviews and in trust. Everything below describes the architectural consequences of running natively inside Salesforce, which follows from how the product is built. Any specific certification, encryption standard, retention period, or compliance claim must be confirmed with your security and compliance contacts before it appears here, and any not confirmed should be removed rather than softened.
Your Data Stays in Your Salesforce Org
This is the most important thing to understand about the security model. Quick Receivable installs into your org. Your customer records, invoices, payments, and collection history live in the Salesforce environment you already control and already had reviewed.
What follows from that:
- There is no separate AR database holding a copy of your receivables.
- There is no separate application login for your team to manage, and no separate password policy to enforce.
- Your existing single sign-on, multi-factor authentication, and session policies apply, because users are signing into Salesforce.
- Your existing IP restrictions and login hour policies apply the same way.
- Access reviews cover it as part of your Salesforce review, not as a separate exercise.
For a security team, this is the practical difference from an integrated AR tool. There is no second system to assess and no data flowing to a vendor-hosted platform to account for.
Record Access
Who can see which accounts and invoices is governed by Salesforce record access: your org-wide defaults, role hierarchy, and sharing rules, combined with the permission sets that come with Quick Receivable.
Common AR patterns:
| Requirement | How it is usually met |
|---|---|
| Collectors see only their assigned accounts | Sharing rules based on collector assignment |
| AR managers see the whole portfolio | Role hierarchy above the collectors |
| Credit analysts see exposure across all accounts | A permission set with broader read access |
| Customer service sees invoices but cannot edit them | Read-only access on the relevant objects |
| Business units cannot see each other's customers | Sharing model separation, set at implementation |
Design this during implementation rather than after. Changing the sharing model once people are working in the system is disruptive. See the administration guide.
Field-Level Visibility
Some AR fields are more sensitive than others. Field-level security lets you control them individually.
Fields worth thinking about specifically:
- Credit limits and risk scores. Often restricted to credit and management. A sales rep seeing a customer's risk score can create an awkward conversation.
- Tax ID and bank details from credit applications. Restrict tightly.
- Internal collection notes. Frank notes about a customer's finances should not be visible to everyone with account access.
- Write-off and bad debt flags. Usually finance only.
Audit Trail
AR data attracts audit questions: who changed this credit limit, who approved this write-off, when was this invoice marked disputed. Salesforce field history and setup audit trail cover changes made in the org.
Decide during implementation which fields need history tracking. Credit limit, dispute status, resolution code, and collector assignment are the usual candidates. Turning tracking on later does not backfill the history you did not capture.
Confirm before publishing: which fields ship with history tracking enabled, whether the package adds any audit logging of its own, how long history is retained, and whether AI call recordings and transcripts are stored, where, and for how long. That last point will come up in every enterprise security review and in any state with two-party consent rules.
Questions Your Security Reviewer Will Ask
Prepare answers to these before the review rather than during it.
- Where is AR data stored, and does any of it leave the Salesforce org?
- Which third-party services does the package connect to, and what data goes to each?
- What does the AI processing send outside the org, if anything?
- What data does the Equifax connection send and receive?
- Who at the vendor can access customer environments, and under what controls?
- What certifications does the vendor hold, and what is their scope?
- How are AI call recordings handled and retained?
Answer each of the questions above on this page before publishing. A security page that raises questions without answering them is worse than no security page. Confirm the full list of remote site settings and outbound connections with engineering, and confirm certification names, versions, and scope with compliance. Differenz System holds ISO 27001, but the certification scope as it applies to Quick Receivable specifically needs confirming before it is stated here.
What's Next
- Administration: permission sets and record ownership.
- Integrations: outbound connections and what they carry.
- Implementation: designing the access model during rollout.
Security questions for your review?
