Personas

A Persona names a job function: Engineer, QA Analyst, Project Manager. Assign a persona to an item when you know what skill the work needs but have not chosen a person yet; later, add a compatible person without losing that choice. Personas are the "role on the work", while access roles are the "role in the organization": being an Engineer grants no permissions, and creating a persona changes nobody's access.

A worked example: a sprint has eight stories that need an engineer and two that need QA. Assign the Engineer and QA Analyst personas up front, group the board by persona to see the split, and let people pick up items that match their persona. Time logged on each item is attributed to the persona it was done under, so the time report can answer "how many QA hours went into this release?".

Turning personas on

Personas are rolled out by DevStride. Until they are enabled for your organization, the Personas entry does not appear in Settings, and the page (if opened directly) reads "Personas are not available for this organization yet." Contact support if you want them enabled.

Setting up your persona catalog

Configure Settings → Organization → Personas (needs the Manage org configuration permission).

1. Click New Persona, enter a name (Persona Name, for example Engineer), and click Create Persona. Active names must be unique; an organization can hold up to 200 personas, retired ones included.
2. Give personas to people: open Organization → Users, edit a member, tick their Personas and order them with Move up / Move down. The first active persona is the fallback used when an assignment has no persona selected, so put their usual one first. See Giving a member personas.

Managing the catalog:

If another administrator changes the catalog while your dialog is open, your save is refused rather than overwriting their work: close the dialog, refresh, and reapply your change.

Assigning people and personas

The Choose Assignee dialog has People and Personas. You can assign only a persona, only a person, or both; Clear removes the whole assignment. DevStride keeps the pair consistent:

The same rules apply to subtask assignment, bulk edits, table and Gantt editing, automations, and the API and MCP tools. Selecting a persona never auto-picks a person from its members. Removing a persona from a member clears them from current assignments that need it; historical time keeps its recorded attribution.

Finding and organizing work by persona

• The Persona filter pill matches the persona assigned to the work, which is different from filtering for people who happen to hold that persona. Persona-only work counts as assigned even while it waits for a named person. See finding and filtering items.
• In a board's 2D view, choose Persona for Rows or Columns; combine it with Status to see work by job function, or with Assignee to see who has taken ownership. Dragging between persona groups follows the compatibility rules above. See board views.

Reporting time and capacity by persona

• User Time Tracking offers Persona as a grouping. Expand a persona total into users, then a user into their entries. Someone who worked in two personas appears under each with only the relevant hours.
• The Time Allocation Matrix offers persona rows for monthly comparisons over your selected hierarchy. Current workload and capacity use the chosen persona, with the person's first active persona as the fallback, without counting their availability once per persona.
• Completed time keeps the persona captured when it was recorded; later changes do not rewrite it. Older time with no captured persona reports as Unspecified.

See User Time Tracking, Time Allocation Matrix and Current Progress.

Personas in automations

Use Persona Updated as a trigger, Persona as a condition, and Change Persona as an action; the same compatibility rules apply, and existing person-based automations keep their meaning. See working with personas in automations.