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.