Search

Submitting an Intelligent Advisor interview sends a SOAP request containing a batch of create, update, and delete operations. These operations are processed as a single batch.

An Incident may be created in temporary, uncommitted storage early in that transaction. Business rules can detect and evaluate that temporary Incident before processing of the full batch has finished. If a later operation or validation fails, the overall transaction is rolled back: the Incident is removed and all related changes are undone.

The business rules that already executed are not automatically reversed. As a result, any action with an external or asynchronous effect—such as sending an email, invoking a process, creating an integration request, or updating an external system—may still occur even though the Incident was never committed to the database. A reference number may therefore appear in the notification, but no corresponding Incident will exist after the rollback.

This behavior is not limited to email-confirmation rules; it can affect any business rule that runs against an object before the interview submission transaction is successfully committed.
 

Recommendations:

Design rules that create external, irreversible, or customer-visible effects so that they run only after the Incident is likely to be fully committed.

• Avoid running these rules immediately on Incident creation where possible. Use a delayed or time-gated approach, such as an escalation, to allow the transaction to complete first.
• Add conditions that confirm the Incident has reached a suitable completed state. For example, require related records or sub-objects that are created only after the relevant processing has succeeded.
• Use an asynchronous follow-up process. Pass the Incident ID to a rule, CPM, or Process Designer process that runs after a short delay and first confirms that the Incident still exists before sending notifications or calling external services.
• Where practical, make downstream integrations that include a verification step. This prevents duplicate or invalid external actions if a transaction is retried or rolled back.
   

For escalation-based approaches, see Popular Answers about Escalations. For asynchronous CPM or Process Designer implementations, see CPM/Process Designer Best Practices and Guidelines