[external] Automatic Task Delegation in WEBCON

External content by Aleksander Damaz

An employee leaves the company. Goes on unplanned sick leave or a team needs to redistribute the workload for a while because one person has more tasks to do than the rest. In each of these situations, the same practical problem comes back: what do you do with the tasks in WEBCON that were assigned to a specific person?

WEBCON solves this problem for tasks assigned to a group — the system dynamically recalculates the group’s current members, so a person who drops out of the group automatically stops “inheriting” such a task (when the task is assigned to the group itself rather than to its members) — or through the Substitutions mechanism.

The problem remains open, though, for tasks that need to be redistributed within a team and that are assigned directly to a specific person (outside the group mechanism) — those stay with that person regardless of whether they still work at the organization. It’s this exact case that “freezes” tasks, and it’s the subject of this article.

Concept: One Form, Two Steps

The entire mechanism fits into one simple administrative form:

• You select a user and load the list of their active tasks.
• For each task, you specify a person to add to it — optionally with a description and a notification email.

Step 1 — Loading the User’s Tasks

The Task item list has an Element column of type Choice field (picker), wired up to the standard Webcon data source All Elements (Process: All). This source is only used to display the element by its ID — it doesn’t decide which tasks make it onto the list, and it also lets you jump straight to the element.

What actually gets loaded is decided by the “Replace item list” action attached to the Load User Tasks button:

SELECT TSK_WFDID AS ElemID

FROM dbo.ActiveTasks

WHERE TSK_User = '[User.Login]'

  AND TSK_ToGroup = '0'

The result (ElemID) is mapped onto the Element column of the Task list.

The filter limits the result to tasks assigned directly and exclusively to that person — i.e., the ones that genuinely require manual intervention.

After the elements are loaded onto the list, I pull in the default system columns (the “Add default columns” option on the element/picker field) — Process, Step, Days in step. This makes the task’s context visible right away, without having to open the element itself.

Step 2 — Filling In the Delegation Data

The remaining columns of the Task list are filled in by the person handling the form:

• Delegate to — a person-type field, the person being added to the task,
• Description — an optional description/reason for the delegation,
• Send email — a checkbox for whether the delegated person should get an email,
• Email message — the content of that email.

Step 3 — the Delegation Mechanism: REST API

The Delegate tasks button triggers an automation using the For Each operator, iterating over the rows of the Task list. On each iteration, the “Invoke REST Web service” action runs, based on a previously defined WEBCON-type connection (Application (OAuth) authorization — i.e., logging in as the registered application, not as a specific user).

Call configuration:

• URL: api/data/v6.0/db/1/elements/{Element.ID}/admin/tasks/assignment
• Method: POST

⚠ Needs parameterization: the content database number (db/1) is hard-coded here. In an environment with a single content database this isn’t a problem, but with multiple databases (multi-content-database) you need to replace this value with a parameter/variable pointing to the correct database for the given process. Also pay attention to which API version is available in your environment (details described in the Platform Compatibility Roadmap).

Request body (JSON):

{

  "task": {

    "userId": "[User.Login]"

  },

  "delegatedTask": {

    "userId": "[Delegate to.ID]",

    "description": "[Description.Value]",

    "sendEmail": [Send email.Value],

    "emailMessage": "[Email message.Value]"

  }

}

Permissions the API Application Needs

The endpoint requires at least one of three permissions:

• App.Elements.Admin.All,
• User.Elements.Admin.All,
• User.Elements.Admin.<ProcGuid> (a permission scoped to a single process).

For the solution to work across all processes in the environment (not just one), the registered API application needs:

• the App.Elements.Admin.All scope at the level of the application registration itself (type: App context),
• an entry on the global Business Administrators list.

Both elements are required here.

When to Run This?

This is an administrative tool, not a built-in WEBCON mechanism — how it’s triggered depends on the organization’s needs. In practice I’ve seen (and it’s feasible to build) several variants:

• manually, ad hoc — the administrator runs the form in response to a request from HR,
• as a step in an offboarding process, if one exists in WEBCON,
• as an automatic trigger after account deactivation in Active Directory,
• as part of handling a long absence.

One important caveat: this solution does not make a permanent change to the task’s executor — it only adds a delegation of the task to the user. No form values or process logic are changed — the mechanism simply grants the specified user additional permission to perform the task in the system.

It’s worth remembering that WEBCON has a built-in Substitutions module, which works well in situations where all of a person’s tasks can be assigned to a single other person — described in more detail in the vendor’s article “Substitutions in WEBCON BPS.” The substitutions mechanism works similarly to the delegation described here — for every active task of the person being substituted, the system creates an additional task for the substitute, without transferring that person’s other permissions to them. What differs is scale and automation: a substitution is configured in advance (a date range, enabled support on a given path/process) and then covers all of that person’s tasks according to the schedule, whereas the REST mechanism described here lets you act manually and selectively on individual, already-existing tasks — including in places where substitutions haven’t been configured beforehand.

Summary

“Orphaned” tasks after employee leaves the company are a problem that WEBCON partly solves on its own — for tasks assigned to a group, or through the Substitutions mechanism. In cases where tasks need to be redistributed within a team, an additional tool is needed — one that, fortunately, can be built entirely on the official REST API. The price of this solution, though, is a service account with very broad administrative permissions — which means this tool itself should be a permanent fixture in the permissions audit, not just a one-off automation that gets configured and forgotten.