Before anyone clicks a workflow button, you can see where the Record would go. The test follows the Record from the button through every Work Trigger that has nobody assigned to it and stops where the next person would receive it, or where the workflow ends. It shows each Work Trigger it passed through, the Activation Rules that matched, the actions it met and the values that changed on the way.


Nothing is routed or saved. The test works on a copy of the Record in memory, so nobody is assigned, no email goes out and no Record or Document changes.


Where to find it

The test is available to administrators. It stays available while an administrator is logged in as another user, which is the way to test a work item that belongs to someone else: use Log In As for that user, open the Record, and the Test buttons are there.


On the Record screen, open the Workflow panel:

  • The Test button at the top of the panel, Test Record Routing, asks where the Record would route if workflow started for it now - the same question the Route button next to it answers for real.
  • Each work item on the Record shows its buttons. The Test button beside a button, Test Button Click, follows that one click.
  • Test All Buttons at the foot of a work item tests every button on it in one go, one row per button. On a Work Trigger that has no buttons it reads Test Trigger Workflow Movement and tests the move that Trigger Workflow Movement on the Work Items report would make.


In search results, the row's Record Actions menu has TEST Record Routing, the same test as the first one above.


What the test does

For a button, the test does what a click does, in the same order: the Working Actions of the Work Trigger the item is on, as a click does, then the button's Visibility rules, its Requirements and its actions. It then leaves the step through its Completion Actions, finds the next Work Trigger the way the workflow engine does, works out who would be assigned there and runs that Work Trigger's Assignment Actions. When nobody is assigned, it carries on the same way until it reaches an assignment or the end of the workflow.


Actions that only set values are run, in memory. Every other action is listed, so you can see that it would have run, but it is not performed. The full list of both is below.


A button with Prompts is tested with the Record as it is now; the test cannot know what a user would type. A Work Trigger in Test Mode shows the users it is set up to go to, not the user who clicked.


Reading the result

The summary has a row per button (one row for a Record test) with three columns: Button, Result and Assigned To. The results are:

  • Advances to (or Routes to for a Record test) - the Work Trigger the item stops at, with who is assigned to it.
  • Done with workflow - no Work Trigger matched after the last step, so the workflow ends there.
  • No routing will be triggered - a Record test found nothing to start.
  • Stays on - the button is set to not advance workflow, so the item stays where it is after the button's actions run.
  • Button is not shown - the button's Visibility rules do not match this Record, so the user would not see it.
  • Button cannot be used - its Requirements are not met; the message the user would see is shown under it.
  • Stops on - a Stop Processing action ended the route at that Work Trigger.
  • Work Item is cancelled and Record is deleted - a Cancel Work Item or Delete Record action would have done that.
  • Waits on - the item cannot move on until its child or parallel work items finish.
  • Loops on - the route keeps coming back to the same Work Trigger with nobody assigned, so the workflow needs a look.
  • Error - the route could not be followed; the message says why.


A warning icon beside a result means the route depends on a value the test could not set. Open the row to see which.


Click a row to open it. There is one card per Work Trigger passed, in order, marked Current Work Trigger on the one the item is on now. Each card shows who is assigned there (or Nobody assigned - passes through), the Activation Rules matched, and a table of the actions met on that step: When (Working, Button, Completion, Assignment or Process Actions), the action, In the test (Run, Not run or Deferred - not run) and a detail column with the field and value. Values changed lists every field the run actions changed on that step, old value to new. Refresh runs the test again.


Actions the test runs

These actions run during a test, on the copy of the Record in memory:

  • Record Field Update, Record Multi-Value Update and Rename Record Field
  • Document Field Update and Rename Document Field, on the work item's Document
  • Work Item Field Update
  • Single Temp Variable and Multiple Temp Variables
  • Run Action Set when it runs immediately; the actions inside it are run or listed by the same rules as any other
  • Action Loop
  • Direct Trigger Link and Stop Processing
  • Throw Exception, which ends the test the way it would end the route
  • Search and Calculate, and Search and Update when it updates the source Record; both read the Records they find and set values on this one


Two exceptions: an update aimed at a Named Record is listed only, because the actions that build Named Records are not run; and a Search and Update set to update the Records it finds is listed only, because those Records would change.


A few more are recognized without being performed. Cancel Work Item and Delete Record end the test with the matching result. The actions that change which Record, Document or user the following actions work on (Set Active Record, Set Alternate Record, Swap Alternate Record, Set Active Document and Set Active User) are not performed, so every action after one of them in the same list is listed only.


Why the other actions are not run

Every other action does something outside the copy of the Record: it sends an email or a text message, calls another system, creates, merges, converts or deletes Documents, creates or changes other Records, starts another route, assigns assets, runs OCR, indexing or AI, and so on. In a test each of those would be a real action with real effects, so they are listed and skipped.

Actions set to run offline (deferred) are listed as Deferred - not run even when they are of a kind the test runs, because they happen after the route has moved on and cannot change where it goes.


When a listed action would have set a field that a later rule reads, the result is a guess from that point, and the test says so: Route from here depends on the field, naming the action that would have set it. The same warning appears when such a field decides whether an action runs, whether a button is shown or can be used, or who a Filtered Assignment picks. To test past the warning, put the value the action would have produced on the Record (or on a test copy of it) and run the test again.


Activation Rules in a test

Rules are evaluated by the workflow engine itself, on the values the test holds in memory, so whatever the run actions changed is seen by the rules that follow. These rule types behave exactly as they do in a real route:

  • Record Value Check, Variable Value Check, Value Comparison, Numeric Check, Date Check, Value In List and Record Type Check, on the Record as the test has changed it.
  • Document Value Check, on the work item's own Document, including changes made by Document Field Update in the test. A Set Active Document is not performed, so a Document Value Check after one still reads the original Document.
  • Work Item Value Check, on the work item's own fields, including changes made by Work Item Field Update in the test. A Record test starts a new route, so its work item has no fields yet.
  • Field Validated, Field REVERSE Validated and Record Hold Check, which read fields on the Record; when a Lookup Table Validator, Add Retention Hold or Remove Retention Hold that was not run would have changed them, the test warns.
  • Team Check and User Internal or External, evaluated for you, the person running the test, or for the user you are logged in as.


The other rule types read things that are stored, which the test cannot change, so they see them as they are now. That is right until an action the test did not run would have changed what they read:

  • Document Existence, Current Document Check and Required Docs - Documents that a Merge Document Template, Merge Data into Document, Create Text Document, Convert Document or Delete/Purge Document(s) action in the route would make or remove are not there yet.
  • E-Form Approval - an Approve E-Form action in the route is not run.
  • OCR/Barcodes Status, Classify Status, Split Status and Index Status - the AI/OCR/Barcode Processing, classification, split and indexing actions are not run.
  • Server Value Check - a Server Field Update action in the route is not run.
  • Record Search - Basic and Record Search - Advanced - Records that a Create Record or Search and Create action in the route would add are not there yet.
  • Work Item Hidden/Visible - a Hide/Show Work Item action in the route is not run.
  • The Asset checks - Assign Asset, Return Asset and Cancel Asset Request actions in the route are not run.
  • Due Date - the work items the test makes up for the Work Triggers it passes through have no due date.
  • Processed Check - the test writes no history, so a Work Trigger passed earlier in the same test does not count as processed.
  • Percentage Check - random, so a test can differ from the real route, and from the previous test.


The test does not warn about these. When a route relies on one of them after an action that was not run, read that part of the result as a guess.


Limits

  • The test runs as the person who asks for it. Variables and rules that depend on the user reflect you, or the user you are logged in as. It does not check that you could really click the button; a real click is refused for anyone the item is not assigned to.
  • Named Records are not built, and the actions that build them are listed only.
  • Values a user would type into a button's Prompts are not known, so the test uses the Record as it is.
  • The test stops with Loops on when the same Work Trigger matches more than ten times with nobody assigned, or after a hundred steps.
  • The result reflects the Record now. Anything that changes the Record before the real click can change the route.