Workflow Execution Order Best Practices

Version 8
    Share This:

    << Other Best Practices



    Execution order is used to control the individual order in which workflow is fired.


    In this document I discuss filters. The reason is that hundreds of filters may execute on the same event, as opposed to active-links who usually run 1-10 at any given event.


    In many cases the execution order is not really crucial for your system to work, but can help you with structure and performance.


    My experience is that these guidelines has helped me a lot to make my workflow understandable, and debugging easier.


    These are the guidelines I try to follow when I am building a new application.


    Execution orderWhat to put thereWhy
    • Reserve for temporary maintenance
    Just save this for later use, to allow you to add a temporary skip-all-filter that will skip every other filter. The typical action would be Goto 1000.
    1 - 9
    • Reserve for Form Commands
    Read detailed discussion on Form Commands. The general idea is to do special data operations here, triggered by a value in a display-only-field ('Clear User Data' = "Yes"), and then perform a Goto 1000 to skip everything else.

    100 - 300

    • Message errors and validations that can stop your transaction
    • Those set-fields operations required to perform your validation

    It is good practice to perform the validation first, to prevent other filters from firing.

    400 - 600
    • Set-fields operations that change your data
    This is a good spot to put the filter that change and extends the transaction.
    700 - 900
    • Push-fields
    • Notifications
    • Run process
    • Integrations

    When you know your transaction is valid, and you have your data in place, you can fire off the filters that transmits your data to other places.

    Filters run in 3 phases, and it might be useful to put the phase 3 actions at the highest execution order. In other words put Notifications and Run process commands at 800+. Phase 3 runs after your data has been committed to the database.


    For the middle range (400-600), many filters are solitary, and do not really depend on other filters. Just leave these at the default execution order of 500.

    Related or dependent filters

    If your filters are dependent on each other, try to stagger and group these filters:

    • INC:INC:251:Check contact:Get firstname lastname
    • INC:INC:259:Check contact:Error

    I have left the range 252-258 in this example, if I later need to add more related filters into this specific validation.


    The exact number here is not important, as long as your are consistent. Guides do not run based on their execution order, but you can easily get confused, if they show up in the same place as other filters. One suggestion is to put them at 999. Another is to use good Object Naming to differentiate them from your ordinary filters.

    Related topics

    Naming of objects tie closely into this, to get good structure in your system.


    Please add comments here to help us extend and fine tune this document!