The Onboarded™ application is designed to be flexible. You can use the custom objects that come with the package, or configure the application to sync data to your existing Salesforce objects.
Key Point: The custom objects included with this package (such as
Onboarded_Employee__c,Onboarded_Employer__c, etc.) are purely optional. Clients can map Onboarded™ data to any Salesforce object that fits their data model.
The package includes pre-built objects optimized for Onboarded™ data:
| Onboarded™ Entity | Default Object | Description |
|---|---|---|
| Employee | Onboarded_Employee__c | Worker/candidate records |
| Employer | Onboarded_Employer__c | Company/employer records |
| Client | Onboarded_Client__c | Client organization records |
| Job | Onboarded_Job__c | Job/position definitions |
| Placement | Onboarded_Placement__c | Employee-job assignments |
| Task | Onboarded_Task__c | Onboarding tasks |
| Form | Onboarded_Form__c | Form templates |
Benefits: Pre-configured fields, ready-to-use page layouts, and optimized for Onboarded™ data structure.
Map Onboarded™ entities to your existing Salesforce objects:
| Onboarded™ Entity | Common Alternatives |
|---|---|
| Employee | Contact, Lead, Person Account, Custom Object |
| Employer | Account, Custom Object |
| Client | Account (with Record Type), Custom Object |
| Job | Custom Object, Opportunity Line Item |
| Placement | Custom Junction Object, Opportunity |
Critical consideration. How you configure Form-related data in your Object and Field Mappings has a direct effect on how tasks are surfaced in the Employee Onboarded and Workflow Onboarded components. The two components depend on different mappings to render form requirements, and both are described below.
The Employee Onboarded component depends on the Form object. It displays Workflows in an accordion format. For each Workflow, it shows a list of form requirements — the forms that need to be completed for that Workflow. This form requirement data is retrieved from the Onboarded_Form__c object (or your equivalent mapped object).
When Form data is retrieved, the component displays:
- A list of required forms for each Workflow (e.g., "W-4", "I-9", "Direct Deposit")
- An Assign button for forms that haven't yet been assigned as tasks
- Progress percentage for each assigned form
- Visual indicators showing which forms are complete vs. pending
If you choose not to retrieve Onboarded Form data:
- Workflows still display in the Employee Onboarded component
- The form requirements list is empty — users won't see which forms are required
- The Assign button is not available — users cannot assign individual forms as tasks from the component
- Overall task progress is still visible in the Workflow Tasks and Other Tasks accordion sections below
The Workflow Onboarded component depends on the Placement form_requirements field mapping. It reads form requirements from a JSON field on the Workflow (Placement) record itself, populated through the Placement object's form_requirements field mapping. This JSON payload contains both the form's metadata (id, name) and the task assignment status for each form requirement on the Workflow.
When the Placement form_requirements field is mapped and populated, the component displays:
- One row per form requirement for the Workflow, in the order they appear in the source JSON
- An Assign button on each unassigned form requirement (creates a Task in Onboarded™)
- Progress information for each assigned form requirement
- Per-task action buttons surfaced by the Task Row (Get Link, View Document, Employer Task, Unlock Task)
If the Placement form_requirements field is not mapped, or the field value on the Placement record is empty:
- The Workflow Onboarded component renders with an empty task list
- Neither assigned tasks nor unassigned form requirements will appear
- The Get Tasks Link button at the top of the component will be disabled (no tasks to include in the link)
Unlike the Employee Onboarded component, the Workflow Onboarded component does not read from the Onboarded_Form__c object — it reads form name and id directly from the JSON payload on the Placement record. As long as the form_requirements field is being kept up to date by sync, the component will display form requirements regardless of whether the Form object is being synced.
When skipping Form object sync may be acceptable. Some organizations may be comfortable not retrieving
Onboarded_Form__cdata if:
- Tasks are assigned automatically in Onboarded™ and don't require manual assignment from the Employee Onboarded component
- Users only need to view overall task completion progress on the Employee Onboarded component, not form-level details
- The organization primarily uses the Workflow Onboarded component, which reads form requirements directly from the Placement's
form_requirementsfield rather than the Form object
If your organization uses the Employee Onboarded component and you want HR representatives or managers to:
- See exactly which forms are required for each Workflow
- Manually assign individual forms as tasks when needed
- Track form-by-form completion status
Then you should retrieve Onboarded_Form__c data. Configure the Form object mapping in Onboarded Setup > Object Configuration.
If your organization uses the Workflow Onboarded component:
- Map the
form_requirementsfield on the Placement object to a Long Text (or Rich Text) field that can hold the JSON payload - Confirm the Placement sync is running so the field stays current as form requirements are added, completed, or unlocked in Onboarded™
Within each Workflow accordion (Employee Onboarded) or the single Workflow task list (Workflow Onboarded), individual tasks expose contextual action buttons depending on their state — Assign for unassigned form requirements, Get Link or Employer Task for incomplete tasks, and View Document or Unlock Task for completed tasks. See the Components page for the full Task Row Actions reference.
If you use your own objects, ensure they include these essential fields:
| Field Purpose | Data Type | Notes |
|---|---|---|
| Onboarded™ ID | Text (External ID, Unique) | Stores the unique identifier from Onboarded™. Used for matching records during sync. |
| Last Sync Timestamp | DateTime | Required only on the Employee object. Tracks when the record was last synchronized. |
The Onboarded™ application provides flexible object mapping configuration, allowing you to store Onboarded™ data in any Salesforce objects that meet your business needs. You can configure the application using:
- Standard Onboarded™ Objects: Use the pre-installed custom objects (
Onboarded_Employee__c,Onboarded_Employer__c, etc.) that come with the managed package - Your Custom Objects: Map Onboarded™ entities to your organization's existing custom objects or standard objects
- Hybrid Approach: Mix and match — for example, use
Contactfor Employees,Accountfor Employers, but useOnboarded_Task__cfor Tasks
Organizations have different data models based on their business processes. This flexibility ensures the Onboarded™ integration adapts to your existing Salesforce architecture rather than forcing you to change your data model.
Example scenarios:
- A staffing agency using
Contactfor temporary workers andAccountfor client companies - An HR department using custom objects like
Candidate__candHiring_Company__cthat were built before implementing Onboarded™ - A franchise organization using standard
Accountobject with custom record types for different entity types
Note: Only users with the Onboarded™ Admin permission set will have access to the Onboarded™ Setup tab.
- Open Onboarded™ Setup. Navigate to the Onboarded™ Setup tab in your Salesforce org.
- Navigate to Object Mapping. Click on the Object Configuration section.
- Select Target Objects. For each Onboarded™ entity type, select the Salesforce object where data should be stored.
- Save Configuration. Save your object mapping configuration.
Important: After changing object mappings, you must also update field mappings to point to the correct fields on your chosen objects.
The Object Configuration section in Onboarded™ Setup provides additional options for customizing how data is mapped and synced:
Use the Create Custom Attribute action to create a new custom attribute mapping for an Onboarded™ object. Custom attributes allow you to map Onboarded™ API fields that are not included in the default configuration.
When to use: When you need to sync additional Onboarded™ fields that are not part of the standard field mappings, such as custom fields you've added in your Onboarded™ account.
Use the Retrieve Custom Attribute action to retrieve and view existing custom attribute mappings that have been configured for an Onboarded™ object.
When to use: To review which custom attributes are currently configured, verify their mapping settings, or before making changes to existing custom attribute configurations.
The Enable Salesforce Record Creation option controls whether the sync process should create new Salesforce records when Onboarded™ records are encountered that don't already exist in Salesforce.
When enabled: New records will be created in Salesforce for any Onboarded™ records that don't have a matching Salesforce record (based on the Onboarded™ ID field).
When disabled: The sync will only update existing Salesforce records; new Onboarded™ records will be skipped until a corresponding Salesforce record is created manually or through another process.
Use the Add Reference Relationship action to configure lookup or master-detail relationship mappings between Onboarded™ objects and their related Salesforce records.
When to use: To establish relationships between synced records, such as linking Employee records to their Employer, or linking Placements to their associated Job records. These relationships are populated during the Link Data operation.
Example: Configure a reference relationship so that the Employee's Employer lookup field is automatically populated based on the employer_id from Onboarded™.