Filter guides

Filter guides are used to create reusable components of filter workflow by adding computational subroutines within filter processing. This provides for more sophisticated workflow solutions and allows easier reuse of functionality between forms.

A filter guide is a list of filters that perform a task on a particular form. You create the filters before you insert them into a guide. Filters that execute in the context of guides are not triggered by the same Execute On conditions that trigger a filter during normal workflow. Filters are evaluated in their order within the guide, subject to redirection by the way of the Go to Guide Label action. If a filter used in a guide does have an execution condition, its execution condition is ignored.

You use three filter actions to implement filter guides:

• Call Guide — Starts the filter guide. Like active link guides, the Call Guide action can be nested, calling yet another filter guide. The number of nested Call Guides cannot be deeper than the maximum depth of the filter action stack. For more information about the Call Guide action, see Call Guide action.
• Exit Guide — Terminates the filter guide. This action is ignored if it is not running inside a filter guide. For more information about the Exit Guide, see Exit Guide action.
• Go to Guide Label — Redirects the flow of execution within a guide to a specific filter. This action is ignored if it is not running inside a guide. If the guide label is not found, this action is ignored as well. For more information about the Go to Guide Label action, see Go to Guide Label action.

Filter guides allow a developer to group a set of filters into a single unit of work (that is, a subroutine) and call only the filters referenced in sequence inside the guide without caring about the execution order of other filters. They also let developers call the filter guide under many different circumstances tied to multiple different forms. In essence, developers can create a piece of functionality that can be called as a unit of work, and not care about the execution order across all filters. In that way, developers can focus on what the filter guide as a unit of work accomplishes. For example, take the following filters with their execution orders:

By design, each filter executes in its own execution order, based on which events trigger the filter action.

By contrast, a filter guide could call these filters, in the following defined sequence:

This same filter guide can be triggered in different circumstances, at different times, from different forms.

You use essentially the same procedures to create filter guides as you do for active link guides. For more information, see Creating guides and the following sections: