Salesforce permissions, scopes, and the integration user

Introw runs in Salesforce under the identity of the user who authorizes the connection. It has exactly that user’s access - no more. Whatever objects, fields, and records that user can read or edit, Introw can; anything gated by their profile, permission sets, field-level security, or sharing rules is gated for Introw too. That is the important part for security review: you control everything Introw can touch by controlling one Salesforce user. This guide covers the OAuth scopes Introw requests, why we recommend a dedicated integration user, and the minimal object and field access - read versus write - your partner program actually needs.

​

Use a dedicated integration user

Because Introw inherits the connecting user’s permissions, connect with a dedicated Salesforce integration user rather than a person’s own login. We recommend this to every customer, and it’s the cleanest way to run the integration: Create the user (a Salesforce or Salesforce Integration license is typically enough), assign a permission set with the access below, and authorize Introw while logged in as that user.

​

Allow the Introw connected app

This is the most common blocker on a first Salesforce connection, and it is worth planning for rather than discovering. Since September 2025 Salesforce refuses OAuth authorization for any connected app that is not installed in the org, unless the authorizing user holds a permission that exempts them. System administrators hold that permission by default, which is why an admin’s own quick test succeeds while the dedicated integration user we recommend fails on the same org. Already-connected orgs are unaffected. Salesforce keeps honouring an authorization completed before the restriction, so this only bites a new connection or a new connecting user. Switching an existing integration to a fresh integration user counts as new. Expect the first attempt to fail, and let it. Salesforce only lists a connected app for your org once the org has actually received a request for it, so there is nothing to install until someone has tried to connect. When the attempt is refused, Salesforce ends the flow on its own page and never redirects back, so Introw records nothing at all: no connection, no error, no half-finished integration to clean up. What you see is Salesforce’s message, “We can’t authorize you because of an OAuth error. For more information, contact your Salesforce administrator.”, with error=invalid_client and error_description=app+must+be+installed+into+org in the URL.

​

Option A: install the app (recommended)

Select Install on the Introw row and confirm. Salesforce converts it into an installed connected app in your org, which means the app now sits under your own access controls instead of Salesforce’s blanket restriction. Then decide who may authorize it. Open Setup > Manage Connected Apps, select Introw, and set the Permitted Users OAuth policy: If you choose Admin approved users are pre-authorized, assign the integration user’s profile or permission set to the app before reconnecting, or the authorization is refused again for a different reason. Prefer this route: the decision is recorded on the app itself, it survives staff changes, it does not widen what anyone can authorize elsewhere in Salesforce, and it is the version a security reviewer will accept.

​

Option B: grant the connecting user the permission

Enable Approve Uninstalled Connected Apps for the user who authorizes Introw, under System Permissions on a profile or, better, a permission set assigned only to that user. They can then authorize Introw without the app being installed in the org.

​

Verify the app is allowed

Reconnect from Introw. The Salesforce approval screen now appears, the connection completes, and back on Connected Apps OAuth Usage the Introw row shows User Count at 1 (your integration user) with the denied-attempt counter no longer climbing. If you installed the app, it also appears under Setup > Manage Connected Apps, where you can revoke it at any time.

​

OAuth scopes

Introw connects via OAuth (a modern External Client App, or a connected app). It requests three scopes: The connection uses PKCE and a rotating refresh token. Scopes define what the token can do at the API level; the integration user’s permissions still decide which objects and fields are actually reachable.

​

What access Introw needs

The principle is simple: Introw only needs access to the objects you embed in the portal or report on - nothing else. Read and write are managed separately per object and field (through the permission set and field-level security), so you can grant read-only broadly and write only where you need it.

​

Minimal baseline (read)

To identify partners and their people, Introw reads a small set of standard fields: Any other standard or custom Account/Contact field you want in Introw (for segments, reports, portal columns) just needs read access on that field.

​

Per object you collaborate on or include

For each additional object you want in the portal or in reporting - Opportunity, Case, a custom object, … - Introw needs two things:

1. Read on the object and the fields you pull in - the properties you display in Introw or expose to partners.
2. Read on whatever links it to a partner - the attribution, whether that’s the OpportunityPartner junction, or a lookup/picklist field on the record. See Attribution in Salesforce.

If you never surface Cases, Introw never needs access to Case. Access tracks exactly the surface area of your program.

​

When Introw needs write access

Reads cover most of the program. Introw needs write access only for the specific, opt-in actions you configure: Everywhere else, Introw follows a safe default: it only writes fields you’ve mapped or a form is set to write, defaults to never overwriting a value that’s already set, and never mass-edits records. See CRM field mapping.

​

How Introw shows you what it is missing

Least privilege only works if a gap is visible. Because Introw inherits the connecting user’s access, a shortfall does not look like an error: it looks like Introw being wrong. A partner count comes back short, a mapped field never lands, a submission saves without half its values. So Introw checks what the connection is actually allowed to do and marks the shortfall on the screen where you would otherwise configure something that cannot work.

• On the integration’s Object linking step, every linked object carries a verdict pill with the reasoning on hover: Read-only, Partly visible, Fields read-only, Record types limited, Cannot read back, and the rest. The panel opens with one line naming the connection and whether the check ran at all.
• On a form’s Automation tab, each CRM object automation the connection cannot write carries a warning, and every unwritable property is struck through in the picker with its reason. No write permission for this connection is the one you can fix; Calculated in your CRM and Managed by your CRM are not.
• Re-check after changing permissions re-probes on demand, so a permission set you just assigned shows up immediately rather than after the cache expires.

What Introw checks is the union of the profile and every permission set assigned to the connecting user: object CRUD, field-level security, the object’s sharing model and any View All grant, and which record types that user holds. Where it cannot check, it says so rather than reporting a clean result. Every CRM error Introw logs is the full map, including what each verdict means and where a refused write is reported.

​

In short

​

Related