Workflow Automation CoE > Flows > Best Practices > Logging and Reporting
Flows Best Practices Logging and Reporting
Check out this Workflow Academy video on Flow and Action Error Handling for detailed instructions on how to use Try and Go back to flow logic, error handler, action error evaluation, etc.
Flow Execution Details generate a great amount of reporting data. This should be considered debug information used at development (in non-production) only, and enabled in production only for troubleshooting or in very low-volume use cases.
The reporting level determines what if any information is saved in the flow execution details. If a flow runs while reporting is off, execution details are not available for the flow. If the reporting level changes, future executions will honor the new reporting level.
- If a flow runs while reporting is activated, execution details are for the flow based on the reporting level.
- Flow and Action reporting can be enabled on a Flow and Action level basis.
- Flow execution details are aggressively purged from the system to save on diskspace, if you require longer term reporting, either write key metrics to a record, or create a Performance Analytics report to summarize and aggregate your reporting details.
- The reporting level has no effect on context and log records.
- Note: QuickAPI runs a flow, subflow, action, or Data Stream action from a server-side script synchronously or asynchronously without creating a flow context, execution details, or other related records.
- Improves performance by eliminating record-keeping overhead.
- Use this API to increase the speed of high-volume processing, for example multiple executions per second, in a production environment.
- No record will exist for the execution attempt or details. Any record keeping will be the duty of the calling method, or as an operation of the flow (for example, using the Log action to write a message to the system log).
Any operation that causes additional write to the ServiceNow database, results in performance impact. As a best practice, limit the number of database writes when possible, to ensure optimal performance of your instance.
- Flow Designer Property: com.snc.process_flow.reporting.level (Default value: Off).
- Keeping reporting OFF on production instance improve flow performance.
- Even with default reporting off, you can opt-in per Flow / Action reporting.
- Logs are still available.
- Testing a flow via Test Button produces execution details.
Flow Reporting options:
- Off: Reporting is deactivated. The system generates execution details only when you test a flow.
- Flows Only: Reporting is activated for all flows and subflows.
- (Default pre-Rome) Flows and Actions: Reporting is activated for all flows, subflows, and actions.
- Flows Actions and Steps: Reporting is activated for all flows, subflows, actions, and custom action steps.
- Developer Trace: Reporting is activated for all flows, subflows, actions, and steps (custom and base system).
Center of Excellence Navigation
- Workflow Automation - Center of Excellence
- Workflow Automation Migration Considerations
- What's new for Workflow Automation?
- Resource Hubs
- Flows
- Decision Tables
- Playbooks
- FAQ
- Training
- Workflow Academy
