Status and field mapping
How provider statuses become Laya columns, what you can remap yourself, and how priorities, points and labels translate.
Last updated
On this page
When a board from another tool lands in Laya, its statuses become columns and its fields become Laya fields. This article explains how that translation works, where it is automatic, and where you can adjust it yourself.
The four Laya status buckets
Every provider's states collapse onto four Laya buckets: Queued, In motion, Done and Hold. The buckets power cross-provider surfaces — master-board columns and the public share view's lanes — while each connected board still shows its own native columns.
Where each provider's columns come from
| Provider | Columns and statuses | What you can adjust |
|---|---|---|
| Jira | Columns mirror the Jira board's own column configuration, so each column maps to the Jira statuses it contains. | Managed in Jira — Laya reads the board's configuration. |
| Azure DevOps | States are grouped using each process's own state categories, discovered per project — never hardcoded state names. | A Column mapping drawer on the connected board lets you override which column each state lands in, per board. |
| monday.com | Status comes from a Status column, or from the board's Groups when no status column exists — detected per board. | A column mapping drawer lets you choose which status, people and date column drives each signal. |
| GitHub | Repository boards read open/closed state plus status-style labels; Projects v2 boards read the board's Status field. | You can override how any status value or label maps to a bucket, per board. |
| GitLab | Open/closed state plus scoped labels (key::value, for example workflow::doing). Pinning one of the project's issue boards makes its label lists the columns. | Pin a different issue board, or 'Project (all issues)', to change the lane map. |
Status mapping on master boards
Master boards blend sources from several tools, so they get their own mapping controls: Board settings → Status mapping. The tab appears on master boards only.
- Pin any source status to a specific master-board column. Pins are applied before the automatic bucket rule.
- Create a new column directly for a status that has no home yet.
- Use Detach or Duplicate & detach to separate a source from the master board.
- Toggle Auto-create new issues: 'When a new issue is created on a connected source, automatically add it to this master board.' It is on by default, and automatic creation currently applies to Jira sources.
How other fields translate
- Priority: Laya's priority levels map to each tool's own scale where priority syncs — for Azure DevOps, onto Priority 1-4. On GitLab, priority arrives inbound, derived from the issue's labels.
- Points and estimates: Jira story points use the estimate field discovered from the board's configuration; Azure DevOps writes Effort or Story Points depending on the work item type; GitLab uses issue weight.
- Labels: Jira labels pair with Laya tags — inbound labels are added as tags; outbound, Laya replaces the full label set, with spaces converted to underscores.
What happens to unmapped values
- On a connected Jira board, a drag into an unmapped column is rejected — nothing is written to Jira.
- On a master board, statuses without a pin follow the automatic bucket rule, and you can create a column for them from the Status mapping tab.
- Provider users you have not mapped stay visible by display name but are not assigned in Laya — see People and assignee matching.
Email support@laya.net — include what you expected, what happened, and a link to the affected board or item so we can help quickly.