To capture time duration data for each case stage with minimal overhead, what should you do?

• A. Detection rule logic to capture event fields and stage metrics.
• B. Write a job to check case progress and update notes with timestamps.
• C. Configure Case Stages in SOAR settings and use the Change Case Stage action in playbooks to capture metrics.
• D. Create a SOAR dashboard that displays actions run, identifies stage, and calculates elapsed time.

Answer: (C)

Capturing time duration data by tracking stage transitions uses the system’s own case lifecycle. When you configure Case Stages in the settings and use the Change Case Stage action within your playbooks, every time a case moves from one stage to another, the platform records that transition along with a timestamp. This creates precise start and end times for each stage automatically, so you can compute the elapsed time for every stage with no extra scripting or polling. It’s low overhead because nothing extra has to run continuously—the timing data comes from the built-in stage-change events and is available for reporting or dashboards as-is.

Other approaches introduce more overhead or fragility. Writing a separate job to poll progress or updating notes manually increases maintenance and can miss transitions. Relying only on a dashboard for visibility doesn’t capture the timing data itself without the underlying stage-change events, which this built-in method provides directly and reliably.