Error Handling

The Onboarded™ application logs every processing failure to Onboarded_Error_Log__c and, for a specific class of live outbound failures, offers a built-in Reprocess capability that lets an admin retry the operation directly from the Error Log record — without manually re-triggering a sync.

Scope. This section covers the Error Log and its reprocess capability. For the separate retry mechanism on outbound requests queued in Onboarded_Sync_Queue__c — automatic backoff retry, the Do Not Retry status, and monitoring the queue itself — see Sync Queue.

Onboarded_Error_Log__c entries are written from several places in the application — inbound sync/webhook failures, batch failures, component errors, and Sync Queue rows that reach Do Not Retry (see Unrecoverable Errors) all produce an entry. Every entry captures Class_Name__c, Class_Method__c, Error_Message__c, Error_Stack_Trace__c, and — where applicable — Impacted_Object__c / Impacted_Record__c identifying the affected record.

Only one category of these logs is eligible for reprocessing: live, single-record outbound Salesforce™→Onboarded™ push failures, tagged Class_Name__c = 'SalesforceToOnboardedQueueable'. Logs from other sources — including the Sync Queue's own Do Not Retry logging (Class_Name__c = 'OnboardedSyncQueueProcessorQueueable') — are not reprocess candidates. That Class_Name__c value is what identifies a log as originating from the queue's own repeated-failure handling rather than a single live push attempt, and the Reprocess component will not offer an action for it.

When a Salesforce→Onboarded™ outbound push fails and creates an Error Log record (Class_Name__c = 'SalesforceToOnboardedQueueable'), the Onboarded™ Error Reprocess component lets an authorized admin retry that operation after the underlying cause has been resolved. The component targets the specific impacted record, so no broader re-sync is needed.

Note: Reprocessing applies only to this specific failure category — outbound Salesforce→Onboarded™ sync errors where the Impacted Record belongs to an object configured in Settings → Object Mappings. If the error type or object is not eligible — an inbound sync error, a Sync Queue Do Not Retry log, or a record type not yet mapped — the Reprocess button does not appear and the component displays a generic "This error type can't be reprocessed." message.

Access is enforced server-side, not just hidden in the UI — an unauthorized user cannot trigger a reprocess by any other means.

1. Open the Onboarded_Error_Log__c record for the failed operation.
2. Locate the Onboarded™ Error Reprocess component on the record page.
3. If the error is reprocessable, the Reprocess button is enabled. If not eligible, a "This error type can't be reprocessed." message is shown instead.
4. Fix the underlying issue first (e.g., correct invalid field data, resolve an authentication problem).
5. Click Reprocess. The button is disabled while the attempt is in flight to prevent duplicate submissions.
6. Click Refresh to see the resolved outcome once the operation completes.

A triggered reprocess doesn't necessarily resolve in one attempt. The application first classifies the failure as transient or terminal:

• Transient (retried automatically): HTTP 429, any HTTP 5xx response, or a raw callout timeout/connection failure.
• Terminal (fails immediately, no automatic retry): any other 4xx response, or a non-callout error such as invalid data, a missing mapping, or a decryption failure.

If a reprocess attempt fails with a transient error, the application automatically self-chains a delayed retry — it enqueues a fresh attempt roughly 1 minute later, up to a maximum of 3 total attempts, with no further action from the admin required. If every attempt is exhausted, the final outcome is recorded as Failed in Reprocess History (below); a terminal failure is instead recorded as Failed immediately on the first attempt, with no automatic retry.

Every attempt — successful or not — is recorded in the Reprocess History panel with the following fields:

No Duplicate Error Logs: Whether a reprocess attempt succeeds, fails terminally, or exhausts its automatic transient-failure retries, the outcome is recorded in the same Error Log's Reprocess History — a new Onboarded_Error_Log__c record is not created. This keeps error tracking consolidated and avoids log proliferation, even across the self-chained retry attempts described above.

The Onboarded™ Error Reprocess Lightning component must be added to the Onboarded_Error_Log__c record page before admins can use it:

1. Navigate to Setup → Lightning App Builder.
2. Open the record page for Onboarded_Error_Log__c (or create one if none exists).
3. Drag the Onboarded™ Error Reprocess component onto the page layout.
4. Save and activate the page.

Once activated, admins with the Onboarded™ Admin permission set will see the Reprocess button, and HR Representatives will see the read-only Reprocess History panel.

Error Logs accumulate over time and consume org data storage. Administrators can purge old logs from Onboarded Setup → Data Operation Settings → Error Log Maintenance.

1. Click Delete Error Logs.
2. Choose a date and time. Every Error Log created on or before that moment will be deleted; anything newer is kept.
3. Review the record count shown in the modal.
4. Click Delete Permanently.

The purge runs as a background batch job, 200 records at a time.

This cannot be undone. Records are hard-deleted — removed from the Recycle Bin as part of the same job — so that storage is reclaimed immediately. Verify the count before confirming.

Permissions: Requires the Onboarded_Admin permission set. The requirement is enforced on the server, not just in the UI.

One at a time: If a purge is already running, starting another is refused until the first finishes.

Reporting: A successful purge writes no Error Log of its own. If any records fail to delete, a single summary Error Log is created with the deleted and failed counts.