# Object Mapping 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. ## Object Source Options ### Package Custom Objects 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. ### Existing Objects 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 | ## Form Data and Task Display > **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. ### Employee Onboarded Component 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 ### Workflow Onboarded Component 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__c` data 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_requirements` field rather than the Form object ### Recommendations 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_requirements` field 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. ## Required Fields for Custom Object Mapping 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. | ## Object Mapping Configuration 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 `Contact` for Employees, `Account` for Employers, but use `Onboarded_Task__c` for Tasks ### Flexibility Rationale 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 `Contact` for temporary workers and `Account` for client companies - An HR department using custom objects like `Candidate__c` and `Hiring_Company__c` that were built before implementing Onboarded™ - A franchise organization using standard `Account` object with custom record types for different entity types ### Setup Steps > **Note:** Only users with the **Onboarded™ Admin** permission set will have access to the Onboarded™ Setup tab. 1. **Open Onboarded™ Setup.** Navigate to the **Onboarded™ Setup** tab in your Salesforce org. 2. **Navigate to Object Mapping.** Click on the **Object Configuration** section. 3. **Select Target Objects.** For each Onboarded™ entity type, select the Salesforce object where data should be stored. 4. **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. ## Additional Configuration Options The Object Configuration section in Onboarded™ Setup provides additional options for customizing how data is mapped and synced: ### Custom Attribute Creation 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. ### Custom Attribute Retrieval 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. ### Salesforce Record Creation 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. ### Reference Relationships 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™.