GlobalAction Hangs after Creating New Workflow

Owned by Square 9 Support
Last updated: Dec 30, 2021

Problem

After publishing a new workflow, you may encounter a problem where some existing workflows no longer process documents. This can occur if the SSAdministrator (or whichever service account you are using) does not have permission to the new workflow's Initiator search.

This will cause one of two possible errors that can be found in the GlobalAction log. By default, the GlobalAction log in versions of GlobalCapture prior to 2.2 can be found in "C:\GetSmart\Workflow.log". As of GlobalCapture 2.2, the GlobalAction log has been moved to "C:\GetSmart\ActionServices\GlobalAction_1" by default. 

Error 1

ENGINE: CRITICAL ENGINE ERROR, UNHANDLED EXCEPTION REFLECTED TO TASK RUNNER.
ENGINE: CRITICAL: Index was out of range. Must be non-negative and less than the size of the collection.

Error 2

ENGINE: Error occurred polling workflow initiator for <WORKFLOW NAME>: User does not have permission to the selected Search or it does not exist.

Solution

To resolve the issue, ensure that the SSAdministrator has permission to run this search.
  1. Log in to the GlobalSearch Web client as an administrative user.
  2. Click the Lock Icon in the top-left corner, next to the GlobalSearch logo (note that this is only accessible to database administrators or members of the SSAdmin group).
  3. Select "User Management".
  4. If the SSAdministrator is secured to your database explicitly, select it from the list of "Secured User & Groups" on the left side of the page. Otherwise, select the SSAdmin group.
  5. Under "Security Components", select "Searches".
  6. Locate the search you are using as the GlobalAction Initiator. Select it.
  7. Check of "View" under "Search Permissions", and click "Apply Security".

For full documentation, please reference the following links: User Management and Manage Search Security

Best Practice

Under most circumstances, you should not have the SSAdministrator explicitly secured to your database. Instead, make sure that the SSAdmin group has full permissions across your database. Because the SSAdministrator is a member of this group, those permissions will be inherited.