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, Employer Task, and onboarding-link (Get Tasks Link / Get Link) 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 Custom Permission Button Gating for setup details.