Notifications
Clear all
Topic starter
06/06/2026 11:35 am
TL;DR: Applications can create Salesforce Lead records on behalf of users without building OAuth plumbing, token storage, or refresh logic, while still relying on per-user access tokens and org-specific instance URLs, according to WorkOS. The governance issue is not convenience but the delegation model: who owns the credential, who can revoke it, and how the access path is reviewed.
NHIMG editorial — based on content published by WorkOS: Create Salesforce leads from your app without building OAuth
Questions worth separating out
Q: How should security teams govern delegated Salesforce writes from applications?
A: Treat delegated Salesforce writes as governed non-human identity activity.
Q: What breaks when an app relies on refreshable third-party tokens without lifecycle controls?
A: The main failure is that access continues to exist outside the normal review cycle, even when users disconnect, orgs change, or tokens are revoked.
Q: How do organisations know if delegated NHI access is still within its intended boundary?
A: Look for clear tenant binding, successful token refresh boundaries, and visible disconnect events.
Practitioner guidance
- Classify delegated Salesforce access as an NHI workload Assign the integration an owner, scope, and review path that reflects its ability to write records into external orgs on behalf of users.
- Separate connection state from application login state Track whether the Salesforce org is connected, disconnected, revoked, or awaiting reauthorisation.
- Bind token use to the correct tenant context Persist and validate the Salesforce org context and instanceUrl for every write action so backend requests cannot drift across tenant boundaries or hit the wrong environment.
What's in the full article
WorkOS's full tutorial covers the operational detail this post intentionally leaves for the source:
- Step-by-step React widget integration and backend token retrieval code for a working Salesforce connection.
- Exact request and response handling for creating Lead records through the Salesforce REST API.
- Concrete examples of error handling when access is revoked, missing, or needs reauthorization.
- Implementation details for production setup with a Salesforce Connected App and redirect URI configuration.
👉 Read WorkOS's tutorial on creating Salesforce leads without OAuth plumbing →
Salesforce lead writes via Pipes: what IAM teams should watch?
Explore further
06/06/2026 12:29 pm
Delegated Salesforce writes are still a non-human identity governance problem. The article removes OAuth implementation effort, but it does not change the underlying identity model. The app is still consuming a delegated credential to act in a third-party org, which places the activity squarely inside NHI governance. The programme question is no longer whether engineering can build the flow, but whether the delegated access is scoped, revocable, and attributable enough for audit and lifecycle control.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when a connected Salesforce org is revoked or misused?
A: Accountability should sit with the application owner and the identity governance team together. The application owner controls implementation and monitoring, while governance owns lifecycle policy, approval, and review. If either side assumes the other is responsible, delegated access can persist without clear ownership.
👉 Read our full editorial: Creating Salesforce leads without OAuth plumbing still shifts IAM risk
