Execution ID isn’t exposed inside the workflow’s JSON — it’s platform metadata about the run itself, separate from invocationId/subscriptionId (which identify the event delivery, not the execution).
You can only get it externally:
External Trigger: returned as workflow-execution-id in the API response at invocation time — capture it there.
Hello Francesco. @Gopi2000’s answer covers the core of it, but one correction on the API detail: the external trigger response field is workflowExecutionId (camelCase), not workflow-execution-id. The endpoint is POST /v3/workflows/execute/external/{id}, and the 200 body looks like:
That only applies to externally triggered workflows though. Your payload shows triggerType: "FIRE_AND_FORGET", which means it’s event-triggered. In that case, ISC fires the workflow asynchronously and no execution ID comes back in any response. The _meta.invocationId and _meta.subscriptionId you’re seeing are event delivery identifiers, not the execution ID.
For event-triggered workflows, the only way to get the execution ID is after the fact: either through the List Workflow Executions API (GET /workflows/{workflowId}/executions), or through ISC Search which indexes workflow execution history events.
No inline variable exists to print it from within a running step. I think this is a platform gap today.
so there is no way to link an event (for example of ADD_ENTITLEMENT) to the relative worrkflow that is adding the entitlement ?
I have for example a workflow of ACCOUNT_CREATED that adds some AD groups when an AD Account is created. But there are a lot of execution and is difficult to link the event of ADD_ENTITLEMENT to the relative workflow execution. My Idea was to add a comment in the block inside the workflow that adds the entitlement. Something like:
%WorkflowName% - %WorkflowUniqueID%
But I think it’s impossibile to add the unique id.
Right ? Is there no way to derive it from the _meta.invocationId the workflowExecutionId ?