No! The custom objects (Onboarded_Employee__c, Onboarded_Employer__c, etc.) are entirely optional. You can configure the application to sync data directly to your existing Salesforce objects like Contact, Account, Lead, or any custom objects you already use. See the Object Mapping page for details.
Ongoing changes arrive two ways: immediately via the real-time inbound webhook whenever Onboarded™ pushes an event, and on a schedule via the event-feed poller, which pulls only what changed since its last run. The recommended poller cadence is at least daily (comfortably inside the 30-day event-feed retention window), but because each run is a lightweight delta pull rather than a full re-fetch, you can safely schedule it more frequently (hourly, for example) if you want Salesforce to stay closer to real time as a backstop to the webhook. Initial data population is performed once by the Onboarded™ ETL when your org is first connected — you do not run an initial full sync from Salesforce yourself. See Data Sync Overview for details.
Yes! Use the SalesforceToOnboardedSync invocable action in Flows to push Salesforce changes to Onboarded™. Configure field mappings with "Outbound" or "Bidirectional" sync direction.
Failed records are logged in Onboarded_Error_Log__c with details about the error. The sync continues processing other records. Failed records can be retried in the next sync.
Batch jobs run as the user who scheduled them, and operations run in USER_MODE. Ensure the scheduling user has:
- The Onboarded™ Admin permission set assigned
- CRUD access to all target objects
- Field-level access to all mapped fields
- Appropriate sharing rules to access records
The application respects Salesforce's field-level security and encryption settings. If you've enabled Shield Platform Encryption on sensitive fields, that encryption applies to synced data.
Contact Onboarded Support, and we can provide you the most recent package. We highly recommend installing the new package into a Salesforce sandbox environment first, and thoroughly test the new package; before installing this into your production org.
The components expose optional Custom Permission gates for these buttons. If your admin has populated the View Document Custom Permission API Name or Employer Task Custom Permission API Name property, only users with BOTH the Onboarded™ HR Representative permission set AND the named Custom Permission will see the button. Without those properties set, the buttons follow the default visibility (HR Rep or Admin). See the Components page's Custom Permission Button Gating section.
On a completed task, Unlock Task lets HR users re-open specific sections of the form so the employee can correct or revise information. Each selected section produces an unlock request to Onboarded™. Unlock requests are processed asynchronously; the row optimistically reverts to incomplete on first success, and a toast indicates all-succeeded, partial-success, or all-failed.
The Employee Onboarded and Workflow Onboarded components decide which state to render (see Component States) by reading the value of the Salesforce field that stores the Onboarded™ Employee ID (or, for Workflow/Placement, the Onboarded™ Placement ID). If the running user's permission sets do not grant field-level read access to that specific field, the query returns no value for it — indistinguishable, from the component's point of view, from the field genuinely being blank. The result is that a user who is otherwise fully permissioned sees the "Send to Onboarded" button on a record that has already been successfully synced, simply because they cannot see the ID that would prove it.
This is most likely to bite you when Employee or Placement is mapped to an object outside the package (a standard object like Contact/Account, or your own custom object) — the package's permission sets only pre-grant field-level access on the package's own custom objects (Onboarded_Employee__c.Onboarded_Id__c, Onboarded_Placement__c.Onboarded_Id__c, etc.). When you map to a different object, you are responsible for granting field-level read access to whatever field stores the Onboarded™ ID — to the Onboarded™ HR Representative permission set, or to whatever permission set/profile your day-to-day users actually have. Do this for every object you map Employee or Placement to, any time you change that mapping.
To verify: In Setup → Object Manager → your mapped object → Fields & Relationships, open the field configured as the Onboarded™ ID for that object mapping, click Set Field-Level Security, and confirm Visible is checked for the Onboarded™ HR Representative permission set (and any other permission set/profile your users are assigned).
On a completed task, Unlock Task lets HR users re-open specific sections of the form so the employee can correct or revise information. Each selected section produces an unlock request to Onboarded™. Unlock requests are processed asynchronously; the row optimistically reverts to incomplete on first success, and a toast indicates all-succeeded, partial-success, or all-failed.
For technical support, contact:
- Email: support@onboarded.com
- In-app: Use the Help menu in the Onboarded™ portal
- Documentation: docs.onboarded.com