People and assignee matching

The same person often exists twice: once in your tool and once as a Laya member. This article covers how the two are paired, what happens when they cannot be, and whose name goes on an edit.

Mapping is explicit, not guessed

Laya does not silently match people by email address or name. When you import work from a connected source, the import includes a Map users step where you pair each provider user with a Laya member. The mapping is saved with that import, and you can skip it and come back later.

When there is no match

• Unmapped provider users keep their display name on the imported item, so you can still see who owns the work in the source tool.
• The item simply arrives unassigned in Laya.
• If a mapped person turns out not to be a member of the workspace when the import runs, that mapping is dropped and the item arrives unassigned — imports never fail because of a people mismatch.
• To get full coverage, invite your team first, or map the remaining people later.

Assignee sync after import

For linked items, assignee changes sync in both directions with Jira only. For Azure DevOps, monday.com, GitHub and GitLab, the assignee on a linked Laya item does not sync in either direction in this version — see What syncs per provider.

Editing assignees on connected boards

Connected boards are different: their people pickers show the provider's own users, and changes write straight to your tool.

• Jira boards use Jira's own assignable-user pickers for each item.
• Azure DevOps accepts a single assignee; clearing the field unassigns the work item.
• monday.com writes the People column as a full replacement of the current set, and can include monday.com teams as well as people.
• GitHub writes the assignee list as a full replacement of GitHub logins.
• GitLab writes the assignee list as a full replacement; on GitLab Free only the first assignee is kept, since multiple assignees are a GitLab Premium feature.

Who the edit is credited to

Attribution depends on how the connection authenticates. For Jira:

• On an OAuth connection, your edit is credited to you in Jira's history if you have linked your own Jira access for that site; otherwise it falls back to the connection owner's account.
• On an API token connection, every edit is credited to the single configured account.
• On a connection made through the installed Laya Board for Jira app, members with usable linked access see a banner offering attribution as 'You' or as 'Laya Board'.

Avatars

Provider avatars appear throughout connected boards. Laya serves them through a signed proxy with a per-provider host allowlist rather than hot-linking provider URLs, and fetches Azure DevOps avatars using the connection's own credentials, since Azure DevOps avatar URLs require authentication.