Find ECC Queue records and MID Server logs for a failing Orchestration Workflow activitySummaryWhen an orchestration activity in a workflow fails, the workflow context will give an error message, but that is often not enough to understand what really went wrong, so you can fix it. If you can see the full error from the probe in the ecc_queue input record, you will know more, and it you had the MID Server's agent log as that activity's probe ran, you may then have all you need.InstructionsFind the ECC Queue records Whenever a workflow runs an orchestration activity, it leaves a breadcrumb in the Agent Correlator field of any ECC Queue [ecc_queue] records, to make it easier for it to match the result back to the workflow later. This value includes the Sys ID of the Workflow Context record. To find the Workflow Context sys ID, open the record the workflow is running for, such as a Change Request, and click the Workflow Context related link. The URL of that workflow context will be something like https://<instance>.service-now.com/wf_context.do?sysparm_query=id=9668c89edb092300b94581f239961945 If 9668c89edb092300b94581f239961945 is the sys_id, then "rba.9668c89edb092300b94581f239961945" will be the ecc_queue record's agent_correlator field value Open the ECC Queue list, and add a filter condition for Agent Correlator "contains" your sys_id, and all ECC Queue records for that workflow context will be shown. You would expect a queue=output record, followed by a queue=input record for each activity in the workflow, and using created timestamps against the started timestamps in the workflow context screen can see which were for which activity. Record the sys_id of the output record. You will need this for searching the MID Server logs. Find the MID Server log entries From the Agent field of the ECC Queue record, you can know which MID Server was given the probe to run. "mid.server.<mid server name>" From the navigation, go to MID Server -> Servers, and then open the record for that MID Server If the record's Status is not Up, then there may be a problem with this MID Server. If it is Up then the problem is likely to be with executing the probe, perhaps credentials or connections. Click the "Grab MID logs, files and thread dump" related link. This tells the MID Server to bring all the log and configuration files back to the instance, from the on-premise server the MID Server is installed on. You can wait several minutes for these logs to appear in the "" related list of the mid server form, or go straight to the ecc_queue to get the data immediately. The records with the logs attached will be queue=input, source=grabLog. The ecc_queue record with name=agent0.log.0 is the most recent MID Server agent (application) log, with older ones names agent0.log.1, .2, .3 etc. When the MID Server runs probes it logs the start and end, and any other messages from the probe. All log entries start with a timestamp, then the thread name, then the message. The thread name includes the sys_id of the ecc_queue output record, and so these entries are easy to find. If you can reproduce your issue on demand, you could run again in debug mode. To increase the amount of logging (significantly!), on the MID Server form, add a Configuration Parameter:mid.log.level=debug If you want maximum logging (maybe too much), you can add mid.log.level=trace