Skip to main content
The same person can reach a plan twice: as the Assignee of a task and as the Resource of a Team Assignment. Without a declared identity that is two rows in the resource view and an allocation counted twice. Identity mapping is opt-in and independent of the picker — a structure can be browsed for a long time before anyone needs the two sides merged. For the model behind it, see Resource Breakdown Structure. Available since version 26.9.0.

Prerequisites

Before you begin, ensure that:
  • A resource breakdown structure exists as Polarion work items — see Set Up a Hierarchical Resource Picker
  • You have administrator rights on the project whose Gantt you are configuring
  • You can add a custom field to the resource work items — that is where the mapping is declared (an advanced, user-side alternative for externally-provisioned deployments is covered under Advanced below)
1

Name the User on Each Resource Work Item

Name the attributes of the resource work item that hold a user. List them in order — the first that resolves to a real user wins:
The built-in assignee is accepted alongside custom fields, so a structure that already assigns each resource to its person needs nothing new.
A resource work item open in Polarion, its custom fields panel showing the field that names the Polarion user the resource stands for
The resource’s own title and the user it names need not match — the mapping is what decides who the resource is, not the title.
2

Confirm Which Project Holds the Resources

Identity lookup reads the resource work items from:
Leave it unset and it falls back to nextedy.gantt.resourceHierarchy.projectId, and then to the project you are configuring. Set it only when identity is resolved against a different project from the one the picker browses — you can name more than one, separated by commas, when resources live in several projects.
3

Check the Merge in the Resource View

Open a Gantt where the same person carries both a Team Assignment resource and assigned tasks. One resource row should now carry both allocations.Two rows for the same person means the mapping did not resolve. Work through the Troubleshooting table below.

Advanced: Resolve Identity from the Polarion User Side

Where an upstream system owns the resource structure and you cannot add a field to the resource work items, the mapping can instead be read from the Polarion user: a field on the user names its resource node (nextedy.gantt.resourceIdentity.userResourceField), matched by default against the resource work item’s ID — or against a field of the node when users are keyed by a personnel number (nextedy.gantt.resourceIdentity.nodeKeyField).
Polarion has no admin UI for adding custom fields to users. A user-side field only exists when your user provisioning puts it there — LDAP/SSO attribute mapping, an import, or the API. Use this direction only when such a field is already present on your users; otherwise declare the mapping on the resource work item as above.
When both directions are configured, the resource-work-item side is tried first and the user side is the fallback. See Resource Hierarchy and Identity Properties for the full property list.

What Carries an Identity, and What Does Not

A container is not a person, so it is not expected to name a user. Where nextedy.gantt.resourceHierarchy.pickableField is configured, the picker resolves an identity only for the nodes it offers for selection — the levels above it are navigation, and a lookup per node is not free.
Nothing Is Merged Until You Configure ItWith neither nextedy.gantt.resourceIdentity.userIdField nor nextedy.gantt.resourceIdentity.userResourceField set, no merging happens at all. A person reachable both as a resource and as an assignee then occupies two rows and their allocation is counted twice — which reads as an underloaded plan.

Troubleshooting

Verification

You should now see:
  • One resource row per person, carrying both their Team Assignment allocation and their assigned work
  • That person’s total allocation counted once rather than twice
  • The picker’s search finding a resource by the login held in any field you named, as it already does for the built-in Assignee

See Also