{"templateId":"markdown","sharedDataIds":{"sidebar":"sidebar-sidebars.yaml"},"props":{"metadata":{"markdoc":{"tagList":[]},"type":"markdown"},"seo":{"title":"Execution Context","llmstxt":{"hide":false,"sections":[{"title":"Table of contents","includeFiles":["**/*"],"excludeFiles":[]}],"excludeFiles":[]}},"dynamicMarkdocComponents":[],"compilationErrors":[],"ast":{"$$mdtype":"Tag","name":"article","attributes":{},"children":[{"$$mdtype":"Tag","name":"Heading","attributes":{"level":1,"id":"execution-context","__idx":0},"children":["Execution Context"]},{"$$mdtype":"Tag","name":"p","attributes":{},"children":["Understanding how and when different users' permissions are applied is crucial for proper configuration."]},{"$$mdtype":"Tag","name":"Heading","attributes":{"level":2,"id":"api-call-context","__idx":1},"children":["API Call Context"]},{"$$mdtype":"Tag","name":"p","attributes":{},"children":["When the application communicates with the Onboarded™ API, it uses the OAuth credentials configured in the Onboarded™ Setup. The ",{"$$mdtype":"Tag","name":"strong","attributes":{},"children":["user who set up the authentication"]}," is effectively the identity used for these API calls."]},{"$$mdtype":"Tag","name":"Heading","attributes":{"level":3,"id":"authentication-user-requirements","__idx":2},"children":["Authentication User Requirements"]},{"$$mdtype":"Tag","name":"ul","attributes":{},"children":[{"$$mdtype":"Tag","name":"li","attributes":{},"children":["Must have the Onboarded™ Admin permission set"]},{"$$mdtype":"Tag","name":"li","attributes":{},"children":["Must have CRUD access on all objects being synchronized"]},{"$$mdtype":"Tag","name":"li","attributes":{},"children":["Must have field-level access to all fields being mapped"]},{"$$mdtype":"Tag","name":"li","attributes":{},"children":["Account must remain active for the integration to function"]}]},{"$$mdtype":"Tag","name":"blockquote","attributes":{},"children":[{"$$mdtype":"Tag","name":"p","attributes":{},"children":[{"$$mdtype":"Tag","name":"strong","attributes":{},"children":["Best Practice:"]}," Use a dedicated \"Onboarded™ Integration\" user account for authentication. This makes it easier to manage permissions and ensures the integration isn't disrupted if individual user accounts change."]}]},{"$$mdtype":"Tag","name":"Heading","attributes":{"level":2,"id":"batch-job-context","__idx":3},"children":["Batch Job Context"]},{"$$mdtype":"Tag","name":"p","attributes":{},"children":["Batch jobs in Salesforce run as the ",{"$$mdtype":"Tag","name":"strong","attributes":{},"children":["user who scheduled them"]},". This has important implications:"]},{"$$mdtype":"Tag","name":"Heading","attributes":{"level":3,"id":"permission-implications","__idx":4},"children":["Permission Implications"]},{"$$mdtype":"Tag","name":"ul","attributes":{},"children":[{"$$mdtype":"Tag","name":"li","attributes":{},"children":["The scheduling user's object and field permissions apply to all batch operations"]},{"$$mdtype":"Tag","name":"li","attributes":{},"children":["Records the user cannot see (due to sharing rules) will not be processed"]},{"$$mdtype":"Tag","name":"li","attributes":{},"children":["Fields the user cannot access will not be updated"]},{"$$mdtype":"Tag","name":"li","attributes":{},"children":["If the user is deactivated, scheduled jobs fail"]}]},{"$$mdtype":"Tag","name":"Heading","attributes":{"level":3,"id":"scheduling-recommendations","__idx":5},"children":["Scheduling Recommendations"]},{"$$mdtype":"Tag","name":"ul","attributes":{},"children":[{"$$mdtype":"Tag","name":"li","attributes":{},"children":["Schedule all Onboarded™ sync jobs with the same user who configured authentication"]},{"$$mdtype":"Tag","name":"li","attributes":{},"children":["Use a user with System Administrator profile or equivalent permissions"]},{"$$mdtype":"Tag","name":"li","attributes":{},"children":["Document which user account is used for scheduling"]},{"$$mdtype":"Tag","name":"li","attributes":{},"children":["Set up alerts if the scheduling user account is modified or deactivated"]}]},{"$$mdtype":"Tag","name":"blockquote","attributes":{},"children":[{"$$mdtype":"Tag","name":"p","attributes":{},"children":[{"$$mdtype":"Tag","name":"strong","attributes":{},"children":["Common Issue:"]}," If sync jobs suddenly stop working, check if the user who scheduled them has had permissions changed or has been deactivated."]}]},{"$$mdtype":"Tag","name":"Heading","attributes":{"level":2,"id":"flow-and-trigger-context","__idx":6},"children":["Flow and Trigger Context"]},{"$$mdtype":"Tag","name":"p","attributes":{},"children":["The application includes invocable methods that can be called from Flows to perform Create, Update, and Delete operations against your Onboarded™ account."]},{"$$mdtype":"Tag","name":"p","attributes":{},"children":[{"$$mdtype":"Tag","name":"strong","attributes":{},"children":["Execution model:"]}," Since these operations require callouts to the Onboarded™ API, they cannot complete within a Flow or Trigger's synchronous transaction. The invocable method itself records the requested work in an internal ",{"$$mdtype":"Tag","name":"code","attributes":{},"children":["Onboarded_Sync_Queue__c"]}," tracking record and enqueues a queueable to perform the callout asynchronously. The user-facing record reads (querying the source records, resolving field mappings) default to ",{"$$mdtype":"Tag","name":"strong","attributes":{},"children":["USER_MODE"]}," and are gated by the running user's CRUD and Field-Level Security. Only the internal sync-queue tracking inserts and the post-callout status writes use ",{"$$mdtype":"Tag","name":"strong","attributes":{},"children":["SYSTEM_MODE"]},", so that the application can manage its own tracking records reliably regardless of who triggered the Flow."]},{"$$mdtype":"Tag","name":"blockquote","attributes":{},"children":[{"$$mdtype":"Tag","name":"p","attributes":{},"children":[{"$$mdtype":"Tag","name":"strong","attributes":{},"children":["Permissions matter:"]}," Because record reads run in USER_MODE, the running user (or the Automated Process user, when a record-triggered Flow fires under that context) must have CRUD access to the objects being synced and Field-Level Security access to every mapped field. Fields the running user cannot see will be silently excluded from the payload sent to Onboarded™. If you observe partial or empty payloads in your sync queue records, audit the running user's FLS access against the configured Field Mappings."]}]},{"$$mdtype":"Tag","name":"blockquote","attributes":{},"children":[{"$$mdtype":"Tag","name":"p","attributes":{},"children":["When using Onboarded™ invocable actions in record-triggered Flows, Process Builders, or Triggers, confirm the user context that the automation actually runs under (which may be the Automated Process user rather than the user who saved the record) and grant that user the necessary CRUD/FLS access through a Permission Set or Permission Set Group."]}]}]},"headings":[{"value":"Execution Context","id":"execution-context","depth":1},{"value":"API Call Context","id":"api-call-context","depth":2},{"value":"Authentication User Requirements","id":"authentication-user-requirements","depth":3},{"value":"Batch Job Context","id":"batch-job-context","depth":2},{"value":"Permission Implications","id":"permission-implications","depth":3},{"value":"Scheduling Recommendations","id":"scheduling-recommendations","depth":3},{"value":"Flow and Trigger Context","id":"flow-and-trigger-context","depth":2}],"frontmatter":{"seo":{"title":"Execution Context"}},"lastModified":"2026-05-29T01:46:02.000Z","pagePropGetterError":{"message":"","name":""}},"slug":"/onboarded_for_salesforce/execution_context","userData":{"isAuthenticated":false,"teams":["anonymous"]},"isPublic":true}