Skip to main content

Execution Logs

The execution log is the history of one workflow. Every time the workflow runs, whether someone started it, a schedule did, or another system called it, the run is listed with its start time, duration, who ran it and whether it succeeded.

Use it to:

  • Check that a run did its job, and download the file it produced.
  • Find out why a run failed, by looking at which step stopped and what the error said.
  • Find one particular run, for example the run that handled order PO-10482.
  • Run a failed run again, or mark it as handled.

To follow failed runs across all your workflows at once, use Workflow Monitoring instead.

Open the log​

Open the Execution logs window in any of these ways:

  • On the Workflows list, open the ⋮ menu on the workflow and choose Execution logs.
  • Inside the workflow, open the ⋮ menu next to the workflow name and choose Execution logs.
  • On Workflow Statistics, open the ⋮ menu on the workflow's row and choose View Log.
  • On Workflow Monitoring, open a run's menu and choose Open workflow logs.

The window is called Workflow logs followed by the workflow's name. You need read access to the workflow to see its logs.

The list of runs​

Each row is one run.

ColumnWhat it shows
Start time / End timeWhen the run started and finished. A run that is still going shows a dash as end time.
DurationHow long the run took.
One column per execution keyThe value the workflow saved for that key, such as an order number. These columns only appear if the workflow defines keys.
Run byThe person who started the run.
StatusSuccess, Failed, Started (still running), Retried or Verified.

A run counts as Failed if it stopped with an error, or if the workflow's custom status marked it as FAILED.

Retried means someone ran it again with the same input. Verified means someone marked the problem as handled.

Narrow down the list​

  • The drop-down at the top right filters by result: All, Failed or Success.
  • The search box finds runs by text, such as a run ID or an execution key value. See Find a run by an execution key.

Read a run​

Select the arrow at the start of a row to open the run. Three tabs show it from different angles.

Results​

A timeline of the run, from Workflow started down to Workflow ended, with the time it took. Each step in between shows:

  • the step type and its step ID (for example rest_api_1),
  • how long it took (completed in a number of milliseconds), and
  • record counts (Records Processed, Successful Records, Failed Records), where the step reports them.

If a step produced a file, such as an Excel file, a Download button appears on that step. If the run was started from a file, Download Trigger File at the top gives you the file it started with.

If the run failed, the failing step is marked in red with the error type and message, and the same message appears at the end of the timeline.

Result details (JSON)​

The complete record of the run as text: what started it and what each step produced. This is where you read the exact data that went in and came out of a step. Two controls help you work with it:

  • Download Result Details saves the run's result data as a file. It appears when the run saved such a file.
  • The copy button copies the whole text to the clipboard, for example to paste into a support ticket or into a test field of a step editor.

M3 Logs​

For steps that call Infor M3, a table of every M3 program and transaction the run used, with the number of successful and failed transactions and the average time. Expand a row to see the input sent and the answer received. The download icon saves that detail as a file. Use it when M3 rejected a transaction and the step's own error is too short to explain why.

Run again, verify or share​

The menu at the end of each row has these actions:

ActionWhat it does
Re-Run WorkflowRuns the workflow again with the same input as this run. The new run appears at the top of the list, and the old one is marked Retried.
Mark as VerifiedMarks the run as handled without running anything. It is hidden once the run is verified.
Copy link to logCopies a web address that opens this run's details directly.
Find originalOn a re-run, searches for the run it was started from. It is greyed out for runs that are not re-runs.
caution

Re-Run Workflow runs the whole workflow again and can repeat its effects. A workflow that posts an order to M3 may post it twice. If the problem was already fixed by hand, use Mark as Verified.

Runs older than 3 months show a clock icon instead of the menu: their details and actions are no longer available.

If you need to correct the input before running again, use Edit payload and resend in Workflow Monitoring.

Execution keys and custom status​

Two optional settings make the log much easier to use. Both are set per workflow, and both read their value from the run itself, so the value can come from the data that started it or from the result of any step.

  • An execution key is a value the workflow saves with every run so you can find the run later, such as an order number, item number or customer ID. Each key gets a name, and each name becomes a column in the list.
  • A custom status is a result the workflow decides for itself. Some systems answer "OK" even when part of the work was rejected, so Vince Platform cannot always tell by itself. With a custom status you define what success means, using the actual answer. Set it to FAILED and the run shows as Failed in the list and in Workflow Monitoring.

Find a run by an execution key​

  1. Open the log of the workflow.
  2. Type the value, such as PO-10482, in the search box.
  3. Open the matching run.

Keys are searchable across workflows too: Workflow Monitoring searches the key values of all the workflows you can read.

Set them up​

  1. Open the workflow and open the ⋮ menu next to the workflow name.
  2. Choose Execution keys. The window shows how many keys you have used and the maximum.
  3. Select New Key, enter a Name, and enter a JSONata Expression that picks the value. For example, $context.data.trigger.body.orderNumber reads the order number from the data that started the run.
  4. To set a custom status, select Add Custom Status. It is added at the top with the fixed name CustomStatus. Its expression should give SUCCESS or FAILED.
  5. Select Save.

In read-only mode the window can be opened but not changed.

For how to choose good keys and write a custom status, see the Error Handling Deep Dive. To see what you can read in an expression, see the $context reference.

Example: find out why order PO-10482 failed​

A colleague says order PO-10482 never reached M3. The workflow has an execution key named OrderNumber.

  1. On the Workflows list, open the ⋮ menu of the order workflow and choose Execution logs.
  2. Type PO-10482 in the search box. One run remains, with PO-10482 in the OrderNumber column and the status Failed.
  3. Select the arrow to open the run. On Results, the third step is red: the error says the customer number is missing.
  4. Open Result details (JSON) and look at what that step received. The customer number is empty in the incoming data.
  5. Fix the source, then choose Re-Run Workflow from the row's menu. The new run shows Success, and the original shows Retried.

Troubleshooting a failed run​

  1. Filter the list to Failed, or search for the run by its execution key.
  2. Open the run. On Results, find the red step. That is where it stopped, not necessarily where the problem began.
  3. Read the error message. It usually names the cause, such as a missing field, a rejected value or a login problem.
  4. Open Result details (JSON) and compare the data going into the failing step with what you expected. If the step comes after a Transform, check the Transform's output first.
  5. For M3 steps, open M3 Logs to see which transaction was rejected and why.
  6. Fix the cause in the workflow or the source data.
  7. Run it again with Re-Run Workflow, or from Workflow Monitoring, where you can also edit the input first. When the case is closed, choose Mark as Verified.

Further reading​

Last updated on