Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

About the Queue-For-Agent method

Updated on May 8, 2019


Agents run activities to accomplish their tasks. To provide information to the agent activities, your application must place entries into an agent queue so the agent knows that there is work to process.

The Queue-For-Agent method takes appropriate data from the work object or assignment that an agent needs to have, and stores that data in a queue entry for the agent.


Suggested Approach

In your application, call the Queue-for-Agent method from within the processing of the object (work object, assignment, etc.) where the agent task is being created. You can call the method directly, or can call the standard @baseclass.QueueForAgent activity.

Call the Queue-For-Agent method using a step page with the class of whatever work object the agent is processing.  NOTE:  In the QueueForAgent activity, this method is called with a blank step page.  It is assumed that this activity is itself being called from one of the processing activities for the work object; when the QueueForAgent activity is called, the call should include the appropriate work-object step page, which then is passed in to the QueueForAgent activity and becomes its primary page.

The Queue-for-Agent method parameters are:




Required. The RuleSet in which the agent is stored.  This should also be the name of the Agents rule in which this agent is contained.


Required. This parameter contains the name of the agent (as defined on the Agents rule).


Optional. This parameter specifies the number of times the system should try to process this entry; the default is 1.  If the maximum number of attempts is made, and the entry is still unsuccessfully processed, the system will treat the item as a failure.

If, for example, a customer has an agent which (among other processing) updates the status of a work object, then the agent must obtain a lock on that work object before changing its status.  The first or second time that the agent attempts to get a lock on that work object, it may fail, if another user has that work object open at the same time.  This parameter allows the developer to handle that situation without an immediate failure; the agent can try the specified number of times to obtain the lock on the work object before failing.



Optional. This parameter specifies the minimum length of time (in milliseconds) that an entry must remain in queue before it may be processed; the default is 0 (the item may be processed as soon as it is entered into the agent queue). 

As an example, a customer may have an entry with a Max Attempts value of “3.”  If the work object is locked (example above), trying to process it again immediately will probably not give the user any time to close it, so the next attempt should be delayed a little; this parameter puts some time in between tries.  Or, a queue entry may be created by work object processing.  If the agent happens to “wake up” and process this entry immediately after it was entered, the work object would still be in use (and locked) by the user, causing agent processing to fail.  Therefore, putting a small delay in before trying to run the agent process could give the user enough time to close the work object and go on to something else.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us