Skip to main content
This guide explains the Settings configuration for credit-hold-override email alerts. For the override workflow itself (who can override, what reasons to record, the modal walk-through), see Order Exceptions and Recovery Choices.

​
What This Alert Does

Whenever a permissioned operator pushes a sales order past a credit-hold gate at confirm time with a typed reason, Arcus can send an immediate email to your finance team. The notification includes:
  • Order number and a link to the order detail page.
  • Customer name and the order total in USD.
  • Hold type (Credit Limit or Manual).
  • The original system-generated hold reason.
  • The override reason typed by the operator.
  • The full name of the user who performed the override.
Recipients usually include the CFO, the Controller, or a finance-team distribution list. The alert is one-way (informational); no action is required for the override to proceed. The override itself succeeds whether or not the email lands.

​
When It Fires

The alert fires every time both of these are true:
  1. A user with the accounts.override_credit_hold permission successfully overrides a credit hold on a sales order.
  2. At least one recipient is configured in your Settings, AND the order total meets the optional dollar threshold.
When recipients are empty, the alert silently skips and no email is sent. When the threshold is set and the order total is below it, the alert silently skips for that order.

​
How To Configure

Open Settings, Approval Workflows, Credit Hold Override Notifications. Fill in:
  • Recipients: a comma-separated list of email addresses. Leave blank to disable the alert. Example: cfo@yourcompany.com, controller@yourcompany.com, finance-team@yourcompany.com. Maximum 2,000 characters.
  • Threshold (USD): only orders at or above this dollar total trigger the alert. Set to 0 (default) to notify on every override regardless of order size. A common pattern is to notify on every override during the first month, then raise the threshold once your team has confidence in the workflow.
Click Save Changes. Settings take effect immediately for the next override.

​
Sample Email

The subject line follows the pattern Credit Hold Override -- Order [number] -- [customer name]. The body has the order total, hold context, override reason, and a button linking back to the order detail page.

​
Audit Trail and Internal Controls

The override workflow is designed to support an internal-controls posture that satisfies common audit frameworks:
  • Segregation of duties: the override permission (accounts.override_credit_hold) is gated separately from order create, order edit, and customer credit setup. A CS rep without the permission cannot override; a finance manager without order-edit cannot create the order. Default role assignments grant the override to Owner, Admin, Manager, and Accountant.
  • Reason capture: every override requires a typed reason of at least 10 characters. The reason is persisted with the order and surfaced in the activity log.
  • Independent notification: the email goes to a distribution list that does NOT include the override operator by default. This gives finance an independent view into who pushed which orders through.
  • Activity log: every override creates two activity rows. The first captures the override action with operator user ID, order ID, original hold reason, and override reason. The second captures the notification fanout result (which recipients received the alert, how many sends failed). If every send fails, a third row records the fanout failure so the timeline never silently swallows the alert.
  • Communication log: each per-recipient email is logged with delivery status. You can verify any specific override email landed by searching the customer or order in your communication history.
These four signals together satisfy the common Internal Control framework for information and communication objectives (timely, accurate notification of management-override events to parties responsible for monitoring controls), as well as the typical detective-control requirement that override transactions in financial workflows produce an audit trail with reason, user, timestamp, and independent notification.

​
Troubleshooting

Check Settings, Approval Workflows, Credit Hold Override Notifications:
  1. Are any recipients listed? Empty recipients means no email is sent (silent skip by design).
  2. Is the threshold higher than the order total? Orders below the threshold are not notified.
  3. Open the order detail page and scroll to the activity log. If the row “Credit-hold override notification fanned to N recipient(s)” appears, the email was sent and may be in spam. If the row “Credit-hold override notify FAILED” appears, every recipient send failed (see next item).
  4. Open Communications, Email History and search by order number. Each recipient gets a row showing delivery status (sent, bounced, complained, etc.).
Every recipient send failed. Common causes:
  • The recipient mailbox bounced (typo, full inbox, or domain blocking).
  • Your email provider is throttling or rate-limiting your account.
  • A configuration issue prevents outbound email from your entity (open Settings, Communications, Email and confirm the connector is healthy).
The override itself succeeded; only the downstream notification failed. Fix the underlying email issue, then either re-enter the override (which fires a fresh alert) or notify your finance team manually for that one order.
Two options:
  • Raise the threshold in Settings so only larger overrides notify (for example, set to $5,000 to alert only on overrides at or above that order total).
  • Remove that recipient from the CSV. Recipients are per-entity, not per-user.
Today the recipient list is a single CSV that applies to every override above the threshold. Per-tier recipients (one list for 0−5K,anotherfor0-5K, another for 5K+) is on the roadmap. As a workaround, set the threshold to your high-dollar cutoff and route the lower-dollar overrides through a different channel (for example, a daily exception report).
  • Order Exceptions and Recovery Choices covers the operator-side override workflow, the modal walk-through, and the credit hold gate logic.
  • Settings, Roles and Permissions controls who has the accounts.override_credit_hold permission.
  • Settings, Communications, Email controls the outbound email connector that delivers these notifications.