Configure automated sync jobs to keep your Salesforce data current with Onboarded™, and control which objects Onboarded™ is allowed to delete in Salesforce.

Important: Batch jobs run as the user who schedules them. Ensure this user has the Onboarded™ Admin permission set and access to all objects/fields being synchronized. See Execution Context for details.

1. Open Onboarded™ Setup. Navigate to the Onboarded™ Setup tab.
2. Go to Data Operation Settings Tab. Click on the Data Operation Settings section.
3. Configure Schedule. Set your preferred schedule using the CRON expression builder or presets.
4. Save and Enable. Save your configuration and enable the scheduled job.

Alternative — Manual Scheduling via Setup. You can also schedule jobs manually from Setup → Apex Classes → Schedule Apex. If you use this method, the Onboarded™ Setup UI will still detect the scheduled job and update accordingly, as long as the job name starts with "Onboarded" (e.g., "OnboardedSyncScheduler"). Jobs scheduled with other names will run but won't be reflected in the Onboarded™ Setup interface.

What "Scheduled Sync" runs. The scheduled sync job dispatches by object selection (see How the sync dispatches by object): the enabled event-sourced objects are drained by the event-feed poller, and if Forms is enabled the Form catalog batch runs too.

Link Data runs separately. Populating Lookup/Master-Detail fields (see Link Data) does not happen automatically as part of your regular sync schedule. If your mappings include relationship fields, schedule Link Data as its own, separate CRON entry.

Recommended cadence: at least daily. Because the poller only pulls what changed since the last run, scheduling it more frequently (for example, hourly) is safe and inexpensive.

Important — Scheduled Jobs Run As The Scheduling User. Salesforce scheduled jobs execute in the security context of the user who scheduled them. This affects CRUD/FLS permissions, sharing rules, and record access.

Best practices:

• Schedule jobs using an integration user or system administrator account with appropriate data access
• Avoid scheduling under individual user accounts that may be deactivated — deactivating the scheduling user will cause the job to fail
• If the scheduling user leaves the organization, reassign or reschedule the job under an active admin account

Select which objects Onboarded™ is allowed to delete in Salesforce. This applies to both inbound webhook notifications and scheduled batch/poller sync — a delete reported by Onboarded™ for a checked object is applied regardless of which channel reported it. Off by default for every object.

Always visible, independent of the master Enable Scheduled Jobs toggle above. These settings govern delete behavior on both the real-time webhook and the scheduled batch/poller sync — turning off Enable Scheduled Jobs does not disable them, since the webhook path doesn't depend on that toggle either.

Deleted records land in the Recycle Bin, not gone immediately. Deletes performed by this feature are standard Salesforce deletes (not a permanent purge), so they're recoverable from the Recycle Bin for the normal retention window like any other delete.

Turning a toggle on retroactively does not replay past deletes. Enabling a delete toggle only affects deletes Onboarded™ reports going forward — records already deleted in Onboarded™ before you enabled the toggle are not backfilled.

The Batch Size setting controls how many records are processed per execution of the Link Data batch chain (and other on-demand batch operations, such as Forms Reset — see below). This setting is configurable in the Onboarded™ Setup interface.

Not used by the event-feed poller. OnboardedEventSyncQueueable fetches a fixed page of up to 500 events per execution and is unaffected by this setting. Batch Size applies to the Link Data batch chain; Forms Reset (below) always runs one page per batch execution regardless of this setting.

• Decrease batch size if you encounter governor limit errors (CPU time, heap size, SOQL queries) due to complex triggers, validation rules, or automation on the target objects
• Increase batch size if Link Data operations are taking too long and you have minimal automation on target objects

Tip: Start with the default value of 200. If you experience governor limit issues, try reducing to 100 or 50. Only increase above 200 if you have tested thoroughly and confirmed your org can handle larger batches.

Forms are a largely-static catalog that is typically built out during initial setup in your Onboarded™ account — often well before your Salesforce org is connected. Unlike the event-sourced objects, forms are not emitted to the /events feed at all, so the poller never syncs them — forms sync exclusively through the Form batch (FormSyncBatch), a full pull of /api/v1/forms. That batch runs automatically when Forms is enabled and a sync fires (see How the sync dispatches by object); Forms Reset is the on-demand version of the same pull, for reconciling the full catalog whenever you need it — for example, right after initial setup, or after adding forms in Onboarded™.

1. Open Onboarded™ Setup. Navigate to the Data Operation Settings section.

2. Locate the Forms Reset heading. Look for the Forms Reset panel, described as:

   Pulls the complete forms catalog from Onboarded and upserts it into Salesforce. Forms are not part of the event feed, so they never sync through the scheduled poller — this batch is how forms reach Salesforce. Run it after initial setup, any time you add forms in Onboarded, or whenever you need to reconcile the local catalog. Safe to run repeatedly.

3. Click Pull All Forms. This button enqueues a full, standalone catalog pull of every Form record from Onboarded™. On success, you'll see: "Forms reset started — the full catalog is being pulled from Onboarded."

Requirements and behavior:

• Admin-only. Only users with the Onboarded™ Admin permission set can run Forms Reset (the button is gated in the UI, and the server-side controller re-checks admin access as a defense-in-depth measure). A non-admin attempt is rejected with "You do not have permission to reset forms."
• Requires Forms sync enabled and mapped. In Object Configuration, Forms Reset requires the Form entity's sync toggle to be turned on and a Salesforce object selected for it. If either is missing, you'll see: "Form sync must be enabled and the Form object mapped before running a forms reset."
• Concurrency guard. Only one Forms Reset can run at a time. If a forms pull is already in progress, a new attempt is rejected with: "A forms sync job is already running. Please wait for it to finish before starting another reset."
• Idempotent and safe to re-run. Forms Reset upserts by Onboarded™ ID, so running it repeatedly reconciles your Form records without creating duplicates. There is no downside to running it again if you're unsure whether it's needed.
• Does not affect the event feed. Forms Reset is a standalone full pull — it runs independently of the event-feed poller and its schedule, and does not change the feed's sync position.

Reference relationships are normally populated two ways: inline as records sync (the webhook and event-feed poller resolve a reference to the related Salesforce record if it already exists at that moment), and by the scheduled Link Data phase. Neither covers the case where you enable a Reference Relationship after the records were already synced — those existing records were applied before that mapping existed, so their lookup fields were never populated and won't be back-filled until the next scheduled Link run.

Run Links Now back-fills that gap on demand, scoped to a single Onboarded™ object so large orgs don't have to reprocess every object. It runs the existing OnboardedLinkBatch locally and makes no Onboarded™ API calls — it resolves lookups purely from data already in Salesforce.

1. Open Onboarded™ Setup. Navigate to the Data Operation Settings section.
2. Locate the Link References panel. Under Link References, click Run Links Now.
3. Choose the object. A modal opens listing only the Onboarded™ objects that have at least one Reference Relationship mapping configured (so you can't pick an object with nothing to link). Select the object whose reference you just enabled, then click Run.
4. On success you'll see a confirmation that the link job started for the selected object; the linkage runs asynchronously across all of that object's records.

Requirements and behavior:

• Admin-only. Only users with the Onboarded™ Admin permission set can run it (gated in the UI, re-checked server-side).
• Requires Link References enabled. The Enable Link References toggle must be on; otherwise you're prompted to enable it first. (With it off, the underlying batch is a no-op by design.)
• Object must have Reference mappings. Only objects that actually have a Reference Relationship mapping are offered in the picker, and the server rejects any other object.
• Concurrency guard. Only one link batch runs at a time; if one is already active, a new attempt is rejected until it finishes.
• Single-object scope. Each run relinks exactly the object you selected — nothing else is touched. This keeps the operation inexpensive on orgs with millions of records.
• Local-only and idempotent. No API calls; it re-resolves lookups from already-synced data, so it's safe to run repeatedly.

When to use: immediately after you add and enable a Reference Relationship mapping for an object whose records are already in Salesforce, to populate the new lookup across the existing records. For ongoing linkage of newly-synced records, the inline resolution and the scheduled Link Data phase handle it automatically.

Outbound work that can't be pushed immediately is deferred to the Sync Queue and drained by a background processor. Normally this is fully automatic. Occasionally, though, records can be left waiting — for example if a processing job stopped before it finished, or a large burst was deferred and no later event has come along to resume it. When that happens the queued records sit unprocessed until something restarts the drain.

Sync Queueable Operations is a self-service recovery panel that detects this condition and lets an admin restart processing with one click. It appears only when it's needed and drains the entire backlog safely.

1. Open Onboarded™ Setup. Navigate to the Data Operation Settings section.
2. Look for the Sync Queueable Operations panel. It appears automatically only when there are records waiting in the Sync Queue (status Pending or Processing) and no processor job is currently running. If the queue is healthy or already being processed, the panel is hidden.
3. Click Process Sync Queue. On success you'll see: "Sync Queue processing has been restarted." Processing runs asynchronously and works through the whole backlog; the panel disappears on the next load once a processor is running.

Requirements and behavior:

• Admin-only. Only users with the Onboarded™ Admin permission set can run it (gated in the UI, re-checked server-side). A non-admin attempt is rejected with "You do not have permission to process the Sync Queue."
• Appears regardless of the scheduled-jobs toggle. The panel is a recovery tool, so it surfaces whether or not Enable Scheduled Jobs is turned on — a stranded queue can be restarted at any time.
• Conditional visibility. The panel is shown only when there is at least one actionable row (Pending or Processing) and no processor Queueable is active. This keeps the Setup page clean when there's nothing to do.
• Reclaims stranded rows. Because the panel only appears when no processor is running, any row still marked Processing is provably orphaned. Clicking the button resets those rows back to Pending and restarts the drain, so nothing is left behind.
• Drains the whole backlog in safe slices. The processor works through a bounded number of records per transaction and automatically chains itself to continue, so a single click recovers the entire queue without hitting Salesforce governor limits — and the paced slices naturally ease back into any Onboarded™ API rate limits that may have caused the backlog.
• Concurrency guard. If a processor is already draining the queue, a new attempt is rejected with "The Sync Queue is already being processed. Please wait for the current job to finish." (In that case the panel is normally hidden already.)
• Nothing to do. If there are no actionable rows, the action reports "There are no Sync Queue records that need processing."
• Safe to run. The operation only restarts processing of records that are already queued; it never creates new work.

When to use: if you notice records lingering in the Sync Queue (for example, rows stuck in Processing with an old last-attempt time, or a Pending backlog that isn't shrinking), open Data Operation Settings and click Process Sync Queue. For day-to-day operation no action is needed — the queue drains on its own.

Batch Sync Exemption Rules allow you to exclude specific records from being synced based on field values in the Onboarded™ API response. This is useful when you want to filter out certain records before they are created or updated in Salesforce.

Feed-only. Exemption rules are evaluated by the event-feed poller only. The real-time webhook does not consult exemption rules — a webhook delivery for an otherwise-exempted record still applies, consistent with the webhook always processing what Onboarded™ pushes (see Feed vs. Webhook Scoping).

When the poller applies a page of events, API records are checked against active exemption rules before being processed. Records that match any active exemption rule are excluded from that sync operation.

Exemption rules can be configured in the Onboarded™ Setup interface. Each rule requires:

• Exclude terminated employees: Onboarded™ Object = Employee, API Field = status, Match Type = equals, Value = terminated
• Exclude test records: Onboarded™ Object = Employee, API Field = email, Match Type = equals, Value = test@example.com
• Exclude records without email: Onboarded™ Object = Employee, API Field = email, Match Type = isBlank

Note: Exempted records are counted in sync statistics but are not created or updated in Salesforce. If an exemption rule is later deactivated or removed, previously exempted records will be synced the next time the poller processes an event for them (a past event for that record is not automatically replayed — the exemption simply stops applying going forward).