# 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. ## Security Model Summary - **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 ## USER_MODE vs SYSTEM_MODE Operations 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™. ### SYSTEM_MODE Exceptions 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. ## Key Security Considerations ### Integration User Access 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 ### Batch Job Context 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. ### Credential Security OAuth credentials (Client ID) are stored securely: - OAuth credentials are stored in protected org configuration - Access tokens are managed securely by the application ### Data Privacy 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 #### Encrypted Field Requirements 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 ### Strict Custom Permission Gating for PII Buttons 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](#custom-permission-button-gating) for setup details.