Maintenance and escalation

These actions are generally safe for a business administrator when done carefully.

Safe Actions

• assign or remove the two built-in permission sets
• activate or deactivate an analyzer
• copy an analyzer to prepare a variant
• review queue entries and retry items in Error
• open the processing log to understand failures
• adjust review-oriented settings such as confidence threshold, approval rules, and tolerances
• place background schedules on hold before planned maintenance
• test connections after credential or endpoint changes

Actions That Need Extra Care

Delete analyzer

• Safe only when the analyzer has no documents in Pending or Processing.
• Deleting an analyzer also deletes its field mappings.
• Deactivation is safer than deletion when you may need the setup again later.

Delete queue record

• Deleting a queue entry also removes its extracted data and match results.
• Do this only if you are intentionally removing processing history for that entry.

Copy analyzer

• This is usually safer than editing a live analyzer heavily.
• After copying, review the new analyzer before activating it.

Retry

• Retry is appropriate for a failed item after you fix the cause.
• Do not repeatedly retry the same error without reviewing the processing log.

Create Document

• Use this only after the document has been reviewed when review is required.

Actions to Avoid Without Implementation Support

• rebuilding or replacing analyzer definitions
• syncing advanced analyzer structure from external configuration when you are unsure of the impact
• changing advanced custom-table behavior
• changing key-generation behavior for imports into custom records
• changing advanced initialization logic

These actions can affect how records are created and may have consequences outside the administration area.

Practical Maintenance Playbook

When operations are healthy:

1. Confirm the queue is moving.
2. Check the number of active analyzers.
3. Review recent errors and repeated review reasons.
4. Confirm schedules are active.
5. Confirm retention still matches policy.

When a change is needed:

1. Prefer copying an analyzer instead of changing a busy live one.
2. Make the change on the copy.
3. Activate the replacement only when ready.
4. Deactivate the older analyzer if capacity is limited.

When to Escalate

Escalate to your implementation or technical support team when:

• connection tests fail after credentials were updated
• many documents suddenly move to Error
• items remain in Processing without clearing
• a needed analyzer cannot be activated because of tier limits
• automatic creation or update of business records behaves unexpectedly
• you need to change advanced target-table behavior or initialization logic

Current Operational Limits

No clear business-admin recovery for stuck Processing items

Users can retry items in Error, but the reviewed pages do not expose a simple cancel, reset, or release action for items that remain in Processing.

What this means:

• if an item stays in Processing, the business administrator may need technical help instead of having a safe self-service recovery action

Queue export is not implemented

The queue page contains an Export to Excel action placeholder, but it currently shows a message indicating it is still to be implemented.

What this means:

• administrators should not rely on built-in queue export for operational reporting at this time

Some advanced analyzer actions are too technical for routine administration

The analyzer card includes advanced actions that can rebuild or replace analyzer structure. These are powerful, but they are not business-admin-friendly and may overwrite existing definitions.

What this means:

• routine administrators should avoid those actions unless they are following a controlled implementation procedure

For document-level failure diagnosis, use Troubleshooting.