Choosing your setup

Connecting a tool takes minutes; connecting it well is a few deliberate choices. This guide covers the decisions that matter before you roll Laya out to a team.

Decide the system of record

When you mirror, the source tool stays the system of record — Laya is a live, editable window onto it, and nothing is migrated. When you import, Laya owns the copy (with a field subset still syncing through the link). Pick deliberately: mirror while the owning team keeps planning in its own tool, and import only when Laya is becoming the place that work is owned. See Mirror vs import.

Private mirror or shared workspace

The Jira and Azure DevOps connect flows ask how the connection should live in Laya:

• Just for me / Connect to my personal workspace — a private mirror in your own workspace. Nobody else is affected, and teammates are never auto-joined. Ideal for evaluating Laya.
• Set up a shared workspace for my team — one workspace your teammates join. For Jira, colleagues who sign in with the same provider and can reach the site are added to the workspace automatically.
• Connect to existing workspace — join the shared workspace that already exists for the site, rather than creating a parallel one.

monday.com, GitHub and GitLab connections do not offer this choice — the connection is created in the workspace you start the connect flow from, so start the flow from the workspace where the mirror should live.

One connection or many

• Jira: a workspace binds to exactly one Jira site, and each site has one canonical shared workspace — if two people race to create it, the second is joined to the first automatically. Plan one shared workspace per Jira site.
• Azure DevOps, monday.com, GitHub, GitLab: a workspace can hold several connections per provider (multiple organisations, accounts or namespaces), so you can bring everything into one workspace.
• Prefer fewer, shared connections over many personal ones for team boards — a shared connection survives any one person's departure better when it is owned and claimable at workspace level.

Rolling out without disrupting teams

1. Start with a private mirror to evaluate — nothing is migrated, so there is nothing to undo.
2. Move to a shared workspace when you want the team in: mirror the boards teams actually use, and leave the rest.
3. Compose a master board when leadership needs one view across tools — sources stay live underneath.
4. Keep editing habits unchanged at first: teams keep working in their own tools, and Laya's two-way sync reflects it. Laya-side editing can grow naturally from there.
5. If sync ever needs a break (say, during a provider migration), pause it per board from Board settings → Integrations — the links survive and resume where they left off.

Avoiding duplicates

• One shared workspace per Jira site. Laya enforces this, and it is the main guard against "the same board exists twice". If you see a duplicate Jira board, check whether someone made a private mirror alongside the shared workspace.
• Importing the same item onto two boards is by design, not a bug — each board gets its own linked card and both stay synced to the same source item. Decide which board owns planning for a given source so people know where to edit.
• Watch the auto-create toggle on master boards. With "Auto-create new issues" on (the default), new items appearing in a connected Jira source are added to the master board automatically. Turn it off per board if the master should stay curated.
• Mirror a board once per workspace. Removing and re-mirroring is always safe; mirroring the same source into several workspaces multiplies the places people can edit.

Finally: sync is last-writer-wins with loop protection in both directions, so simultaneous edits resolve predictably — but a clear "who edits where" convention beats relying on conflict handling. See Conflicts, loops and safety.