Best Practices For Designing GlobalAction Initiator Searches

GlobalAction initiator searches are built and configured much like other searches, however, their function is very different from searches that are meant to actually return documents for client use. 

Here are some best practices for GlobalAction Initiator Searches.

Step-by-step guide

1. Secure your Searches
   
   1. Most users do not need to have access to GlobalAction Searches. This should be considered an administrative function and the GA searches should be secured appropriately.
2. Use Flags
   1. Flags are most commonly statuses, such as "New" or "Pending." You'll almost always want to include some sort of status flag.
   2. You'll want to use Flags in ADDITION to your normal search parameters. For instance, if you want to have a GA fire off when a certain invoice threshold is attained, you should also be stipulating a status flag such as "Waiting Level 2 Approval."
   3. Having an easily visible flag can also help users understand where in the workflow the document is/should be.
   4. Once a document enters the flow, the flag should immediately be changed. In the event the workflow fails or errors, this will prohibit the document from looping through the workflow without user input.
3. Utilize Complex Logic where applicable
   
   1. GlobalAction Searches can utilize complex logic (nested and/or statements) which can return very specific documents for very specific workflow
   2. It's worth noting that in most cases, however, simple logic will return documents properly.
4. Preface your GlobalAction Searches
   1. In environments with a lot of GlobalAction Workflows, finding those Searches may be difficult. Square 9 Professional Service's best practice recommendation is to preface all GA initiator searches with "GA -" so they can be easily identified and edited.

Do not edit GlobalAction initiator searches without unpublishing their workflows first. Even minor changes to the GlobalAction initiator search can lead to unexpected results
Do not edit GlobalAction Workflows while there are batches running through the workflow. Removing queue or validation nodes when there are processes waiting in them can lead to the GlobalAction Engine crashing. You should instead unpublish the workflow and allow all of related processes to finish and then edit the workflow

Alternately you can create an unpublished copy of the GlobalAction workflow and then make changes to that one and put it into production afterwards.

Related articles