Templates, tasks, and groups
The Task Library holds three kinds of building block, on three tabs. They sound alike and are not interchangeable, so this page explains what each one is for.
If you want to get something built, your first deployment is the place to start. This is background.
The three kinds
| What it is | |
|---|---|
| Task Template | A script definition with configurable parameters. |
| Task | A pre-configured single action, ready to drop into a workflow. |
| Task Group | A reusable sequence of pre-configured steps that run together. |
Why a template is not enough on its own
A template describes what a script does and what it needs to know, not what it should do on any particular occasion. Installing software is a template. Installing a particular package, from a particular source, is a decision somebody has to make.
That decision is what turns a template into a task. You configure the template once, filling in its parameters, and the result is a task you can use over and over without answering the same questions again.
This is why the Task Templates tab describes them as needing configuration before use in a workflow. A template with unanswered parameters cannot run, and a workflow containing one cannot be published.
Why groups exist
A task group is a sequence rather than a single action. It exists so a multi-step procedure you perform often stays consistent every time, rather than being reassembled step by step in every workflow that needs it.
Where a task is one decision made once, a group is a sequence agreed once.
Where they come from
Everything in your library is one of two sources, and the Source filter separates them.
Custom. Built by someone in your organization. Fully editable.
Marketplace. Installed from the Marketplace. Read-only, and pinned to the version you installed. To change one, clone it first, which gives you an editable custom copy and leaves the original intact.
The distinction is deliberate. A marketplace component that could be edited in place would no longer be the thing you installed, and updates to it would have nothing predictable to apply to.
Status
Every item is Active, Inactive, or Deprecated, and the status filter narrows the list to one of them. Status is about whether something should still be reached for, rather than about whether it works.
To take one of your own items out of use without deleting it, choose Deactivate from its action menu. It stays in the library as Inactive, and Activate brings it back.
The Status field in the task and task group editors sets any of the three, including Deprecated, when you create an item or edit one.
In batch mode, Activate and Deactivate set the same status on every selected item. A selection that mixes active and inactive items is offered Activate, and afterwards every item in it is active.
Editing with others
Several people in your organization can have the same template, task or task group open at once. The editors save when you choose Save, and only the fields you changed are sent. When two of you change different fields, for example one renames a task group while the other edits its description, both changes are kept.
When someone else saved a change to a field you also changed, your save is held back and a notice appears in the editor:
Someone else saved changes to this task while you were editing. Keep your changes or use theirs?
| Choice | Effect |
|---|---|
| Keep my changes | Saves your version over theirs. |
| Use theirs | Drops your change and shows what they saved. |
A task group's steps count as one thing here. If you both changed its steps, even different ones, you get the notice.
Activating or deactivating an item from the list never asks: it sets the status you chose, and an editor open on that item treats the new status like any other change someone else saved.
Restoring an older version from Version History acts on the template as you last loaded it. If someone saved a change since then, the restore is refused, nothing changes, and the editor shows their change so you can try again.
How this reaches a deployment
Nothing in the Task Library runs on its own. A task or group becomes work when it is a step in a workflow, and that workflow is published.
The workflow editor's Task Templates panel is where library items are picked from while you build. What you publish is a snapshot including their content, so a workflow keeps behaving as it did on the day you published it even if the library moves on underneath. See Versions and publishing.