Choosing Recipients and Assignees
Both Task Settings and Notification Settings ask the same question: who? Both answer it through the same picker — Assignment Options on a task setting, Recipients on a notification setting.
The picker's tabs are not just different lists of the same thing. One of them behaves fundamentally differently, and choosing correctly between them is what decides whether your configuration still works a year from now.
The two kinds of choice
Fixed identities
The User, Role, Position, Organization Unit and User Group tabs let you pick a specific identity from a list. The choice is stored as that identity and does not change until somebody edits the state again.
This does not mean the people are fixed. A role, position, organization unit or user group is resolved to its current members at the moment the task or notification is produced — so adding a person to the Quality role next month means they start receiving that work automatically. Only picking an individual User ties the configuration to one person.
Fields on the record — the Hierarchy tab
The Hierarchy tab is the different one. Instead of picking an identity, you pick a field on the record itself — for example a document's Owners, a nonconformity's Team Leader, or a risk's Responsibles.
Nothing is decided when you configure it. Each time a record reaches that state, the system reads that field on that particular record and routes the work to whoever is in it.
Fixed identity → "always the Quality Manager position"
Hierarchy (field) → "whoever is the Team Leader of this record"
This is what lets a single state configuration serve thousands of records that each have a different responsible person.
Reach for the Hierarchy tab whenever the right person depends on the record rather than on the process step. "The document's owners must approve the cancellation" is a Hierarchy choice; "the Quality Manager must approve every cancellation" is a fixed one.
The tabs
| Tab | What you pick | Resolved when |
|---|---|---|
| Hierarchy | A field on the record that holds one or more identities | Each time a record reaches the state |
| User | One named person | Fixed at configuration |
| Role | A functional role | Members resolved when the work is produced |
| Position | A position in the org chart | Holder resolved when the work is produced |
| Organization Unit | A department or site | Members resolved when the work is produced |
| User Group | A maintained set of people | Members resolved when the work is produced |
| A plain e-mail address | Notifications only — see below |
You can combine entries from several tabs in one configuration.
The E-mail tab
The E-mail tab appears only on Notification Settings. It is deliberately absent from Task Settings.
A notification is a message — anything with an inbox can receive one. A task is a unit of work that somebody owns, completes, and is measured on. It has to belong to a system user, and an e-mail address cannot own a task. That is why the tab is offered in one place and not the other.
The tab covers two different needs:
A fixed address. Type an address by hand — quality@yourcompany.com, a shared mailbox, a distribution list. Useful when the recipient is a function rather than a person.
An address stored on the record. Pick a field that holds an e-mail address. This exists for people who have no user account at all — an external requester who submitted something through a public portal, for instance, has an address on the record but no identity in the system. Without this, there is no way to write back to them.
An address configured here receives e-mail, and nothing else. It produces no task, no in-app notification, and no record of having read anything. If you need evidence that a specific person acknowledged something, they need a user account and a task.
What appears in the Hierarchy tab
The tab shows a tree of the record's fields that can hold an identity. Not every field appears — only those the product has marked as assignable.
If you expect a field and cannot find it, look for a row displaying a raw technical key such as EntityProperty:QDM:Document:Owners instead of a readable label. That means the field is available but its label has not been translated yet; report it rather than working around it.
Common mistakes
Assigning to one named user. The configuration is correct until that person changes role, goes on leave, or leaves the company — and then it silently routes work to somebody who is not going to do it. Prefer a position or a role.
Using Hierarchy for something that is not per-record. If every record routes to the same approver, a fixed identity is clearer and easier to audit than a field path.
Leaving the recipient list empty. An empty configuration is not an error — it produces no work at all, silently. If a state seems to be passed through without anybody being asked, check whether its assignment options actually have rows.
Expecting an e-mail recipient to complete something. See the caution above. E-mail is one-way.