Managing Instance Logging Levels 🆕

Managing Instance Logging Levels

Introduction

Flows for APEX v26.1 adds a new operational capability: you can change the logging level of a running process instance while it is still executing.

This is intended for real-world incident handling. If one instance is behaving unexpectedly, you can increase logging for that instance only, gather the detail you need, and then reduce the level again afterwards.

This avoids the operational cost of turning full debug logging on for every process instance.

When to Change a Running Instance

Typical scenarios include:

• a process instance appears to be stalled or behaving differently from similar cases
• a timer, background task, or expression is failing intermittently
• you need more detail from one live case without increasing logging for the whole system

In most cases:

• move from 2 to 4 first if you want more operational detail
• move to 7 if you are investigating Enterprise Edition AI-assisted behavior and want AI rationale and recommendation auditing
• move to 8 only when you need full debug-level logging including process-variable change history

Flow Monitor Workflow

The Flows for APEX application exposes the current instance logging level in the Flow Monitor instance details view.

The intended operator workflow is:

1. Open the process instance in Flow Monitor.
2. Review the current status and logging level.
3. Raise the logging level for that instance.
4. Re-run or observe the failing behavior.
5. Review the new log entries.
6. Lower the logging level again when the investigation is complete.

This is the preferred approach when one live instance needs temporary extra logging.

API for Runtime Logging Changes

The same capability is available in the admin API.

begin
  flow_admin_api.set_process_logging_level
  ( p_process_id    => 12345
  , p_logging_level => 8
  );
end;
/

This procedure changes the logging level stored on the process instance itself.

Logging Levels for Running Instances

Level	Name	Recommended use
0	none	Disable logging for the instance
1	abnormal events	Error-focused logging
2	major events	Normal production visibility
4	routine	More detailed operational tracing
7	AI intent auditing	Enterprise Edition AI rationale, recommendation, and explainability logging
8	full / debug	Deep troubleshooting, including variable changes

7 is intended for cases where you need AI intent and rationale auditing without going all the way to full variable tracing. 8 is extremely useful during investigation, but it will create more log volume than the lower levels. Use both selectively and temporarily where possible.

Relationship to System and Diagram Defaults

At process creation time, Flows for APEX calculates the initial logging level from:

• the system default logging level
• the diagram minimum logging level
• any logging level requested when the instance was started

The runtime API is different: it changes the logging level for the existing instance directly. This makes it useful as an operational override during an investigation.

For the broader logging model, see Event Logging and Auditing.

Suggested Incident Playbook

For a problematic running instance:

1. Start with the current instance level as-is.
2. Raise to 4 and reproduce or wait for the next execution step.
3. If the issue relates to AI-assisted behavior, consider 7 before moving to 8.
4. If the issue still is not clear, raise to 8 temporarily.
5. Review instance, step, and variable history.
6. Capture the diagnosis.
7. Return the instance to a normal production level.

This gives you targeted diagnostic detail with the least possible impact on the rest of the platform.

Related Topics

• Event Logging and Auditing
• Configuration Parameters
• Instance Archiving and Purging