CRM Integration Permissions: Check Access Before Sync
Approve CRM integration permissions against one written workflow before connecting an app. Check which records it can read, which fields it can change, whether a permission includes deletion, and how you will stop future access. A connector set to sync three fields may still hold credentials that can reach much more.
Start with a simple acceptance rule: every requested capability needs a job, an owner, and evidence of its boundary. Below, an executed nine-probe exercise shows why identical sync settings can coexist with six, four, or zero extra permitted operations in a deliberately simplified model. The downloadable inputs make the difference inspectable without connecting a production CRM.
This review suits teams buying a connector, adding enrichment, or handing CRM data to an automation service. It does not replace testing the connector's actual authorization model. If you are still defining the workflow, begin with the CRM requirements checklist, then bring the access questions into your HubSpot and Salesforce evaluation or Pipedrive and HubSpot shortlist.
CRM integration permissions: define the smallest useful job
Write the integration's purpose as an operation, rather than a product category. “Connect enrichment” leaves almost every boundary open. “Read approved contacts' work emails, read their companies' names, and update a qualification flag” gives you something to check.
For each operation, record:
- The source object and the action: read, create, update, delete, or another explicit operation.
- The included records, such as one region, pipeline, or approved segment.
- The fields needed, including relationship keys that make the result usable.
- The identity under which the connector operates.
- The destination and anyone else who receives a copy.
- The business owner and the person who can revoke access.
Separate a data mapping from an authorization boundary. A mapping says what a workflow intends to send. A CRM-enforced restriction says what a request is allowed to retrieve or change. A connector may enforce its own limits too, but record which system enforces each limit and what happens if the configuration changes.
Use the CRM field ownership guide to decide who may update the qualification flag. If the integration also changes owners, that is another operation to review against your lead routing rules. Do not let a convenient field mapping quietly redefine the sales process.
Review access at three separate layers
A useful review distinguishes the app's grant, the connected identity's applicable permissions, and the connector's configured behavior. Their relationship depends on the CRM, authentication model, endpoint, and feature. Do not assume every product calculates access in the same way.
| Layer | Question to answer | Evidence to retain |
|---|---|---|
| App grant | Which endpoints and operations do the granted scopes enable? | Scope names, endpoint mapping, authorization date |
| Connected identity | Which user, account, record, or field restrictions actually apply? | Identity and applicable permissions, plus test results |
| Connector behavior | Which permitted operations will this workflow use? | Mapping, filters, write rules, and configuration owner |
Treat the first two rows as things to verify in the platform's documentation and a permitted test environment. Treat the third as part of the connector's operating contract. A green sync status answers whether a job ran; it does not establish that the credential had only the access you intended.
Read access can include more than the object name suggests
Pipedrive's scope and permission reference maps contacts:read to persons and organizations as well as related endpoints for notes, files, and filters. Its contacts:full grouping includes creation, updates, and deletion. The documentation also describes accepting or denying the requested scope set as a whole.
The buying question is therefore broader than “does the app need contacts?” Ask which endpoints the selected scope exposes and which account restrictions still apply. A read-only connector can still receive information the workflow does not need. A connector that updates contacts may require a grouping that includes additional actions. These are documented permission groupings, not results from our own Pipedrive account test.
Optional scopes do not guarantee a narrow installation
HubSpot's scope documentation distinguishes required, conditionally required, and optional scopes. Required scopes are needed for installation; optional scopes can be customized during authorization. Endpoint documentation identifies the scopes an operation requires.
Ask the connector vendor which permissions are necessary for your selected feature and which belong to features you will not use. Then compare that answer with the grant actually approved. An optional permission that someone accepts is still part of the installed grant. Record the result, rather than relying on the label “optional.”
The authorization model matters as much as the user name
HubSpot's user-level app documentation distinguishes account-level access from user-level access tied to per-user permissions. Its support table also lists feature differences, including no webhook support for user-level apps at the verification date.
Do not assume connecting a restricted user's account automatically restricts every app to that user's view. Confirm the specific app's model and supported endpoints. A narrower model may also omit a feature your workflow requires. That trade-off belongs in the selection decision, rather than appearing as a surprise after purchase.
These three primary-source pages were checked on October 26, 2026. The examples explain what to inspect; they do not rank the vendors' overall security or promise identical controls across plans and integrations.
CRM integration permissions: replay nine access probes
We created and executed a small Python authorization exercise on October 26, 2026. It uses invented contacts C01 and C02, companies A01 and A02, and note N01. The job requires three operations: read C01's email, read A01's name, and update C01's qualification flag.
Download the replay script and complete probe inputs and results. Run python3 replay.py with Python 3.10 or newer to reproduce the saved output. Assertions verify the listed operation IDs and confirm that all three required operations remain available.
The configured workflow is identical in all three profiles. The authorization predicates change:
- Broad: every probe is permitted.
- Object/action: contact reads, company reads, and contact updates are permitted. Contact deletion and note reads are excluded.
- Constrained principal: the same object/action rules apply, followed by an explicit record-and-field allowlist containing only the three required operations.
The third profile is an idealized server-enforced restriction. It is not a claim that any named CRM or connector can express this exact allowlist. Likewise, the second profile treats update and delete as independently grantable; a real scope may bundle them.
| Probe | Operation | Broad | Object / action | Constrained |
|---|---|---|---|---|
| P1 | Read C01 email | Allow | Allow | Allow |
| P2 | Read A01 company name | Allow | Allow | Allow |
| P3 | Update C01 qualified flag | Allow | Allow | Allow |
| P4 | Read excluded C02 email | Allow | Allow | Deny |
| P5 | Read C01 phone | Allow | Allow | Deny |
| P6 | Update C01 owner | Allow | Allow | Deny |
| P7 | Delete C01 | Allow | Deny | Deny |
| P8 | Read N01 note body | Allow | Deny | Deny |
| P9 | Read excluded A02 name | Allow | Allow | Deny |
What the output demonstrates
The broad profile permits all nine probes, including six outside the intended workflow. The object/action profile permits seven, including four outside the workflow. The constrained profile permits only the three required probes. None blocks a required operation.
P4 and P9 expose the record boundary. P5 exposes the field boundary for reads. P6 exposes the field boundary for writes. Those four remain permitted after the object/action grant is narrowed. The sync configuration never changes, so reviewing only its selected fields would miss the difference between the profiles.
This is a result of authored policy predicates, not a discovery about vendor behavior. No CRM account, OAuth token, customer record, network request, deletion, or message send was involved. The nine selected probes are neither a representative sample of CRM APIs nor a risk score. Use the structure to design actual acceptance tests with your administrator.
Turn the model into a demo request
Give the vendor one approved test record and one excluded test record. Ask them to demonstrate the intended reads and updates, then demonstrate the boundaries separately. An empty sync result for the excluded record is weaker evidence than a verified authorization denial: the connector may simply have filtered it out before making a request.
Where direct authorization testing is permitted, have the administrator use an approved sandbox and non-sensitive fixtures. Do not test deletion against a live customer record to prove a buying point. If a bundled grant necessarily allows deletion, record that capability honestly and decide whether the workflow justifies accepting it.
Check export, copies, and ongoing access separately
“Export disabled” needs a precise meaning. A dedicated bulk-export permission and repeated reads are different paths. If the app can retrieve individual records, ask whether it can enumerate the included set and retain those responses. The absence of one export feature does not by itself establish that CRM data cannot leave through another allowed path.
Your CRM export completeness review can help identify the records, associations, activities, and files that matter. For permission review, reverse the question: which of those items should this connector never receive?
Keep three separate exit questions:
- How do we stop new requests and background jobs?
- How do we verify that the old connection can no longer access the CRM?
- What happens to copies already held by the connector or another destination?
Do not equate disconnecting an app with erasing previously copied information. Ask for the vendor's documented retention and deletion process and retain the answer with the integration record. Use the CRM deletion policy checklist to track destination states and prevent an approved removal from being undone by a later sync.
Also ask what happens when the connecting employee changes roles or leaves. Name an operational owner who can recover the workflow without casually reconnecting it under a more powerful account. Access recovery should preserve the approved boundaries; a successful reconnection alone is insufficient evidence.
Keep a short permission review record
A useful record can fit on one page. It should let the next administrator explain why the integration exists and reconstruct what was approved.
| Record item | Example for the synthetic workflow |
|---|---|
| Purpose | Qualify approved contacts using company context |
| Needed reads | C01 email and A01 company name |
| Needed write | C01 qualification flag |
| Excluded capabilities | Other records, phone, owner changes, notes, deletion |
| Enforcement evidence | Scope mapping plus applicable record/field checks |
| Owner | Named CRM administrator and workflow owner |
| Exit evidence | Revocation check and destination-copy procedure |
| Review trigger | New feature, scope request, owner change, or reconnect |
Use actual groups and policies in your own record rather than copying these invented IDs. Store credentials in the appropriate secret system, not in the review document. Retain identifiers and evidence only to the extent needed for the review.
Revisit the record when a feature is enabled, a permission request changes, or a reconnect occurs. Fold routine checks into CRM data hygiene. If activities are part of the connection, pair access review with a CRM activity sync audit: sufficient access and complete delivery are separate questions.
Decide when broader access is acceptable
Some useful connectors require permissions broader than one small workflow. Rejecting every bundled scope can rule out a practical integration. Accepting every request because the app is familiar leaves the decision unexplained.
Choose among three concrete responses:
- Reduce the enabled features or ask for a narrower supported installation.
- Use a different connector or architecture with boundaries you can verify.
- Accept the documented extra capabilities with an accountable owner and a reason tied to the business value.
A narrow user-level tool may fit interactive work but fail an account-wide background process. A broad automation connector may fit that background job while demanding a more careful review of destination copies and operational ownership. Judge the actual workflow and grant together.
Include the administrative work in CRM total cost of ownership. A connector that saves a subscription but needs repeated manual access repair may cost more to operate. Put the required boundary tests into your CRM implementation checklist before launch.
Frequently Asked Questions
What are CRM integration permissions?
They are the capabilities an app receives to access CRM data or perform operations. Review the granted scopes, the authorization model and applicable identity permissions, and the connector's configured behavior. Record and field boundaries need their own evidence.
Does a sync filter limit what the app can access?
It may limit what the configured workflow processes. It does not by itself prove that the CRM rejects requests outside the filter. Confirm which system enforces the boundary and test the actual authorization path where permitted.
Is read-only access enough to protect unnecessary data?
Read-only access removes some modification paths, but it does not establish which records, fields, notes, or files are readable. Check the scope's endpoint grouping and applicable restrictions against the workflow's data needs.
Can a permission to update records also allow deletion?
Yes, a product can group those actions together. Pipedrive's documented contact full-access scope is one example. Check the exact grant and supported controls rather than inferring separate delete protection from a connector's update-only configuration.
What should we check after disconnecting a CRM app?
Verify that the old connection cannot make new requests, that background processing has stopped, and that responsibility for retained destination copies is clear. Follow the documented revocation and data-retention procedures for that specific integration.
Bring the access boundary into your CRM shortlist
Choose the workflow first, request the exact grant and authorization model, then test both the allowed path and the excluded path. Keep any accepted extra access visible in the decision record.
Use Pipedrive vs HubSpot to compare the broader sales and marketing fit, or HubSpot vs Salesforce when evaluating your CRM operating model. Bring this permission record into the demo so the selected platform and connector have to support the boundaries your team actually needs.
