Using Assigner Tasks

The most common way to assign a task is to use the "Recipients" configuration in each task. This is the best option when a process step is predictable and flows consistently. But what about process steps that are ad-hoc and require human intervention?

Enter the world of Assigner tasks. Assigner tasks are used to provide additional task assignment flexibility in your processes whether the assignment of tasks needs to be manual or is particularly complex.

Let's take a look at each type of Assigner Task:

• Task Assigner: Allows a specific person to manually assign a task to a user or group of users.
• Form Assigner: Allows any end-user to decide who will complete future tasks by answering questions in a form.
• Dynamic Assigner: Allows the use of SQL and collected form data (or other request-specific information) to define task recipients.

Examples of when you would use each

Task Assigner

Let's say you have a "gatekeeper" or "resource manager" who regularly handles the assignment of tasks. Their job is to choose the best resource based on their intimate knowledge of the work and the team. Using the Task Assigner makes sense here because you can set up someone as the gatekeeper, give them the team members to choose from and you're good to go.

Form Assigner

Now let's say you have a different situation where you have a team of Resource Managers, which is not uncommon in larger organizations, and when someone requests a project, it could go to any of those Resource Managers. A Form Assigner is the best way to go here because you can send a form to any Resource Manager that allows them to choose who they want to assign the project.

Dynamic Assigner

The dynamic assigner is the task to use when the rules get updated from time to time and would be easier to maintain in a database table.

Let’s say you have a delegation of approval hierarchy, but it varies based on the dollar amount, project type, and location. That could be a hard set of rules to set up directly, but pretty easy to represent in a database table.

The table could include:

• Approval Level ($)

• Approver group or id

• Project Type

• Location

The query could look something like this:

• Select contact_id

• From contact

• Where [Approval Level] = @Amount

• And [Project Type] = @ProjectType

The other use case might be if you have data that does not exist in the Integrify request. With a query or stored procedure, you can do more complicated logic and also access non-Integrify databases to determine the correct answer.