Security Overview

Understanding the security model of the Onboarded™ application is essential for proper configuration and compliance. This section covers key security concepts administrators should understand.

• USER_MODE Operations: Most operations respect the running user's permissions
• Permission Set Based Access: Access controlled through Onboarded™ Admin and Onboarded™ HR Representative permission sets
• Secure API Communication: OAuth 2.0 authentication with encrypted credential storage
• Error Logging: All sync errors are logged for troubleshooting and accountability

The Onboarded™ application primarily operates in USER_MODE, which means:

• All database operations (queries and DML) respect the running user's object-level and field-level security
• Users can only access records and fields their profile/permission sets allow
• CRUD (Create, Read, Update, Delete) permissions are enforced automatically
• FLS (Field-Level Security) restrictions are applied to all queries and updates

What This Means for You: The user account performing sync operations must have the appropriate permissions on all objects and fields being synchronized. If a user lacks access to a field, that field will not be updated even if data exists in Onboarded™.

In limited circumstances, the application operates in SYSTEM_MODE (bypassing user permissions). In every case, SYSTEM_MODE is scoped to internal tracking records owned by the application — never to your business data:

• Error Logging: Error records are written to the Onboarded_Error_Log__c object regardless of user permissions, so that diagnostic information is always captured even when the running user lacks Create access to the log object.
• Internal Configuration and Status Tracking: System timestamps, sync status flags, and last-sync markers on the Custom Settings and Custom Metadata records use SYSTEM_MODE to maintain data integrity across users and contexts.
• Onboarded™ Sync Queue Records: When invocable methods need to defer work to an asynchronous queueable (to avoid Flow queueable limits and to satisfy Salesforce's callout-after-DML rules), the application inserts, updates, and deletes Onboarded_Sync_Queue__c tracking records in SYSTEM_MODE. The records and fields being synced for the user (read from your source objects) are not affected by this; those reads continue to honor the running user's CRUD/FLS in USER_MODE.

These SYSTEM_MODE operations are limited to internal system management. Your business data reads and writes still respect the running user's CRUD and Field-Level Security — meaning fields a user cannot see will be silently excluded from outbound payloads, and fields a user cannot write will not be updated from inbound payloads. See the Execution Context page's Flow and Trigger Context section for a practical example.

The user who configures the API authentication will be used for making calls to the Onboarded™ API. This user must have:

• The Onboarded™ Admin permission set assigned
• Access to all Salesforce objects where Onboarded™ data will be stored
• Field-level access to all fields that need to be synchronized
• Appropriate sharing rules to access records that need updating

Scheduled batch jobs run as the user who scheduled them, not the user who installed the package. This is critical because:

• The scheduling user's permissions determine what records can be queried and updated
• If the scheduling user loses access to certain objects/fields, sync operations for those objects/fields will fail
• If the scheduling user is deactivated, scheduled jobs will fail

Best Practice: Use a dedicated integration user or system administrator account to schedule batch jobs. Ensure this account remains active and retains necessary permissions.

OAuth credentials (Client ID) are stored securely:

• OAuth credentials are stored in protected org configuration
• Access tokens are managed securely by the application

Consider these data privacy aspects:

• Field-level security can restrict access to sensitive synced data
• Sharing rules control record-level visibility
• Error logs may contain field values — ensure appropriate access to the Error Log object

If a mapped field uses Classic Encryption (Encrypted Text field type), the user who scheduled the batch operation must have:

• Edit permission at the Object level
• Edit permission at the Field level for the encrypted field

If your organization uses Shield Platform Encryption, the user running the batch must also have:

• The View Encrypted Data system permission
• In addition to the Object and Field Edit permissions listed above

The Employee Onboarded and Workflow Onboarded components expose optional Custom Permission gates for the View Document and Employer Task buttons. When configured, these gates require BOTH the Onboarded™ HR Representative permission set AND a named Custom Permission — neither the Onboarded™ Admin permission set nor the System Administrator profile alone bypass them. See the Components page's Custom Permission Button Gating section for setup details.