Skip to content
PulsVaultDocs
Get started
Solo ProTeamBusinessEnterprise

Task Workflows

Task Workflows in PulsVault are delegated action-and-approval workflows over your vaults, secrets, and settings — with assignees, watchers, a status board, and one-click apply for the change being requested.

Task Workflows turn "someone needs to do something to a secret" into a tracked, auditable workflow. A task is not just a to-do: it can carry a target (a vault, a stored secret, a note, or an app-config setting) and a requested action the assignee applies in one click — rotate a credential, review who has access, or update a configuration. Tasks live at Task Workflows in the console (/console/tasks), with a board, a list, and inbox tabs for the work that concerns you.

Which plans include this

Task Workflows, Projects and the Calendar are available from Solo Professional upward (Solo Professional, Team, Business and Enterprise). A few capabilities are Team and above only: assigning tasks to other people (delegation), adding other people as watchers, targeting organization resources, and requiring approval before an action is applied. On Solo Professional you work on your own tasks. See Plan comparison & limits.

What a task is#

Every task has a small, consistent shape:

Part What it is
Title & description The ask, in plain language. Descriptions support rich text.
Priority Critical, High, Medium, or Low.
Due date Optional deadline; overdue tasks are surfaced in their own tab.
Scope Where the task lives: a project, a single vault, or nothing for general work. See Projects.
Target The specific thing the task acts on (optional).
Requested action What should happen to the target when the task is done.
Assignees & watchers Who does the work, and who follows along.
Tags Free-form labels, with suggestions from the project's vocabulary.

Each task also gets a key for easy reference — ENG-42 when it belongs to a project with a key prefix, or a generic TSK-… key otherwise. Keys are numbered per project, so two projects can both have a task numbered 42.

Tasks act on secrets, so they respect zero-knowledge

A task references a target by its id and carries a proposal (the requested action and an optional payload). It never contains your plaintext secrets. When an action needs a new secret value, that value is supplied securely at apply time — never stored in the task itself.

Targets and requested actions#

The power of a PulsVault task is the target + action pairing. You attach what the task is about, then choose what the assignee should do to it. The available actions depend on the target type:

Target Requested actions available
General (no target) Manual completion
Vault Manual completion · Change member access · Remove member
Vault item (a stored secret) Manual completion · Update item · Rotate credential · Archive item
Note Manual completion · Update note · Archive note
DevOps secret Manual completion · Write a new version
App config Manual completion · Update configuration
Organization member Manual completion · Grant access · Revoke access
Role Manual completion · Grant role · Revoke role
Permission Manual completion · Grant permission · Revoke permission

Every target offers Manual completion; the rest depend on what the target actually is. Each action is spelled out under the picker as you choose it:

Action What it asks for
Manual completion The assignee does the work and marks the task done — no automated change.
Update item / Update note Replace the contents. Your device encrypts the secret fields (and a note's whole content); the server never sees those in plaintext.
Rotate credential Generate and store a fresh value for a vault item.
Archive item / Archive note Move it to the trash. Reversible — it is never destroyed.
Write a new version Write a new version of a DevOps secret. See below.
Update configuration Propose configuration changes the assignee can review and apply in one click.
Change member access Change what a member may do in a vault.
Remove member Remove a member's access to a vault.
Grant / revoke access Request that a role or permission be granted or revoked.

DevOps secrets as a task target#

Solo Pro Team Business Enterprise

A task can target a DevOps secret — a value on the machine plane, addressed by its project, environment, namespace and secret path — and request that a new version be written to it. That turns "rotate the production database password" into a reviewable, assignable, audited task instead of someone doing it by hand at 2am.

The target records all four addressing segments, so the task always names the exact secret even if a namespace is later renamed. Requesting a DevOps-secret target needs the DevOps Secrets entitlement; without it the target type is not offered.

The one action that may carry a plaintext value — and the rules around it

Every other action is either zero-knowledge (your device encrypts the payload) or carries no value at all. A DevOps secret is different: it is server-decryptable by design, so this is the one action where a plaintext value may be supplied. Four rules bound it:

  • The value is never stored on the task. It is supplied once, at apply time, and is never persisted on the task, never echoed back, and never written to the audit log. A task carries a proposal, not a secret.
  • Applying requires a fresh identity check. The same step-up you need to reveal a DevOps secret is required to write one from a task, so a stale session cannot rewrite production.
  • A vault-plane target can never receive one. This is a startup assertion, not a review convention: the server refuses to boot if any action that accepts plaintext is ever wired to a vault-scoped target. Vault data is zero-knowledge and the server must never receive its plaintext.
  • An operator can switch it off entirely. A deployment can refuse server-decryptable task writes outright, leaving every other task action working.

Drift: the target may have moved#

Actions that write to something record the target's version at the moment the task was raised. If the target changes before the task is applied — someone else rotated that secret, or edited that item — the applier is warned that what they are about to overwrite is no longer what the task was written against, and must explicitly acknowledge it before proceeding.

Without that acknowledgement the write is refused rather than silently winning. Drift checks apply to updating a vault item, rotating a credential, updating a note, and writing a DevOps secret.

Targets are attached by selection, never by pasting an id

The task modal lets you browse and pick a vault, secret, note, app-config key, or your organization. Many contextual entry points (for example, Request policy change on the Generator settings) open the task with the target already attached and locked, so it always points at the right thing.

Creating a task#

  1. Open Tasks and choose New task, or use a contextual "Create / delegate task" action from a vault, item, or settings page.
  2. Give it a title, and optionally a rich-text description, priority, due date, and tags.
  3. Choose where it lives — a project, a single vault, or nothing at all. Choosing a project can prefill its default priority and suggest its tags.
  4. Optionally attach a target and choose the requested action.
  5. Assign teammates and save — or save as a draft to finish later.

The board and the list#

The Tasks surface offers two views of the same data:

  • Board — a kanban with a column per status: Draft, Open, In progress, Blocked, In review, and Done. Move a card to change its status.
  • List — a compact, sortable table for scanning many tasks at once.

Above both sit the inbox tabs, so you can jump straight to the work that concerns you:

Tab Shows
Summary A dashboard of counts and recent activity.
All Every task you can see.
Assigned to me Tasks where you're an active assignee.
Created by me Tasks you opened.
Watching Tasks you follow without owning.
Overdue Past-due tasks that aren't yet Done, Cancelled, or Archived.
Archived Tasks moved out of the active board.

A filter bar narrows any tab by search text, status, priority, target type, scope (a project or a single vault), tag, or due date. Your active tab and view are kept in the URL, so a link reopens the same view.

The same surface inside a project#

Every project has its own Tasks tab, and it is this exact surface — the same inbox tabs, board, list and filters — scoped to that project.

"Scoped to that project" means the project and every vault it owns, rolled up into one view. A project with no vaults at all still has a working board, because a project is a task scope in its own right. When it owns more than one vault, a row of vault chips appears above the board so you can narrow to a single one, and the project's own scope selector is hidden — the project is the scope while you are inside it.

Lifecycle and status#

Tasks follow a defined state machine — not every status can jump to every other:

From Can move to
Draft Open, Cancelled
Open In progress, Done, Cancelled, back to Draft
In progress Blocked, In review, Done, Cancelled
Blocked In progress, Cancelled
In review Done, back to In progress
Done Archived
Cancelled Archived

The detail view only offers the transitions that are legal from the current status, so a task can't end up in an inconsistent state.

Delegation, watchers, and approval#

Team Business Enterprise

When you assign a task to a teammate, they can Accept or Decline it from the detail drawer, and the response is recorded in the task's activity. Watchers follow a task without being responsible for it. Comments and a full activity log keep the conversation and the audit trail in one place, and updates arrive in real time as teammates act.

Some capabilities depend on your plan's entitlements. The first, second, third and fifth rows are Team and above; targeting a DevOps secret also works on Solo Professional:

Capability Requires
Assigning tasks to other people Task delegation
Adding other people as watchers Watchers for others
Targeting organization resources (app config, members, roles, permissions) Organization targets
Targeting a DevOps secret DevOps Secrets
Requiring approval before an action is applied Approval workflow

Applying the requested action#

When a task carries a real action (anything beyond manual completion), the detail view shows the proposed change and an Apply control. Applying executes the change against the target — for example, writing a proposed configuration update in one click. If approval is required, the task passes through review first.

Sensitive actions require a fresh identity check

Applying an action that changes access or writes a DevOps secret triggers a re-authentication challenge before the change goes through, so a stale session can't quietly grant a role or rewrite production. That covers changing or removing vault access, granting or revoking a role or permission, changing an organization member's access, and writing a new version of a DevOps secret. If you see a re-authentication prompt, that's this protection at work.

Automatic tasks#

Not every task is created by hand. PulsVault can open tasks automatically from system signals — for example a credential nearing expiry, a validation that needs attention, or a policy condition. These arrive in your inbox like any other task, tagged by their origin so you can tell them apart from work you or a teammate created.

Was this page helpful?