Administration

The Administration area provides tools for configuring Wayd, managing users, controlling feature visibility, and connecting to external systems.

Settings lists its pages in a side menu, in groups:

Group	Pages
Access	Users, Roles, Identity Providers
Organization	Holiday Calendars, Team Member Roles
Planning	Estimation Scales (with the planning-poker flag)
Product Management	Product Tags (with the product-management flag)
PPM	Expenditure Categories, Project Lifecycles, Scoring Models
Work Management	Work Types, Work Statuses, Work Processes
System	Scheduling, Sprint Metrics, Feature Flags, Status Workflows, Connections, Imports, Background Jobs, Messaging

The menu shows only the pages your permissions open, and hides a group with none; the filter box above it narrows the list. Opening Settings takes you to the first page you can use.

Deployment configuration

Everything below this section is managed from the Wayd UI. A few things are set outside the app — in configuration files or environment variables — and are the responsibility of whoever runs the deployment:

Topic	What it covers
First-Run Setup	Creating the first administrator account on a fresh deployment via the one-time bootstrap token, and verifying security headers afterward.
Security Headers	Clickjacking and content-type protections, sent on every response. On by default — you only need this if Wayd must be embedded in an iframe, or your edge already sets these headers.
Identity Providers	Connection details for Entra ID and other OIDC providers. Created in the UI (see below), but the app registration and redirect URIs are configured on the provider's side.
Local Authentication	The JWT signing secret, required for password-based login. Must be set per deployment.
Data Protection key	Encrypts connector credentials at rest. Losing this key makes every stored PAT and API key unrecoverable — back it up outside the deployment system.
Database	Connection string and provider settings.

These pages live in the developer documentation

They are shared with contributors, so they include implementation detail alongside the operational guidance. Each section above links to the part you need.

User Management

Users

User accounts control access to Wayd. Each user has:

• Display Name and Email
• Login Provider — How the user authenticates (set at creation; changed only through the identity-provider actions below):
  • Microsoft Entra ID — Single sign-on via Microsoft Entra ID
  • Wayd — A local account: username/password authentication with JWT tokens
  • Any other OIDC provider configured under Identity Providers, reached through Change Identity Provider
• Employee — The employee record the account is linked to, if any. PPM and sprint changes are attributed to it, so an account without one cannot make them
• Roles — Permission groups that control what the user can see and do
• Status — Active or Inactive, and Locked while a lockout is in force

Account operations (the user's Actions menu; each needs Permissions.Users.Update, except Manage Roles, which needs Permissions.UserRoles.Update):

• Activate Account — Enable a user account
• Deactivate Account — Disable a user account
• Unlock Account — Unlock an account locked due to failed login attempts
• Reset Password — Admin-initiated password reset (local accounts only, forces change on next login)
• Change Identity Provider — Stage a move to a different OIDC provider, or from a local account to an OIDC provider (see below). Cancel Pending Provider Migration withdraws a staged move
• Convert to Local Account — Immediately switch an OIDC user to password-based login (see below)
• Manage Roles — Choose the roles the user holds

Local users created by an administrator have a Must Change Password flag that requires them to set a new password on first login.

A user's detail page carries an Activity section: the changes made to the account — its details, roles, lockouts, password changes and identity-provider moves — together with the history of every personal access token the user owns: each token created, renamed, given a new expiration, revoked or deleted, and by whom. A token entry names the token it was raised on. See Activity Log.

Creating users

Administrators create accounts from Settings → Access → Users → Create User. This is the path for provisioning a user before their first sign-in — for example when a provider's auto-registration is off, or for local (Wayd) accounts.

The form captures the user's details, their Login Provider (set here and immutable afterward), a password for local accounts, and their Roles.

Things to know:

• At least one role is required. You must assign one or more roles when creating a user — there is no default role applied automatically. A user with no roles has no permissions, so the form won't submit until at least one is selected.
• Login provider is permanent. The provider chosen at creation can't be changed later through editing; use Change Identity Provider to move a user between providers.
• Microsoft Entra ID users sign in from one tenant. Their first sign-in from that tenant, with a matching email, links the account. If your Entra provider allows only one tenant it's used automatically; if it allows several, pick it in Sign-in Tenant. A sign-in from any other tenant is refused. To change the tenant before they've signed in, use Set Sign-in Tenant on the user's page.
• Roles can be adjusted any time afterward from the user's detail page.

Tenant migration

When your organization moves users from one Microsoft Entra ID tenant to another, you stage the migration in bulk from the provider page. The rebind completes automatically the next time each user signs in from the new tenant — they don't need to do anything special, and their UserId, permissions, and links to other records (work items, audit history, etc.) are all preserved.

This lives on the provider's detail page (Settings → Access → Identity Providers → [provider]), and only appears for a Microsoft Entra ID provider configured with two or more allowed tenants (there must be tenants to move between).

Workflow:

1. On the provider detail page, open the Actions menu and pick Migrate Users to New Tenant.
2. In the dialog, choose a source tenant and a target tenant (both from the provider's allowed-tenant list). Wayd lists the users currently on the source tenant who don't already have a migration in progress.
3. Select the ones to move (up to 500 at a time) and click Stage migration. Wayd reports how many were staged and, if any selected users no longer qualify, how many were skipped.
4. The Active Migrations section on the provider page lists everyone with a staged-but-incomplete migration, showing their source and target tenant and when it was staged.
5. Nothing else changes until each user signs in. Sign-ins from the old tenant continue to work normally.
6. When a user next signs in from the new tenant, Wayd detects the staged migration and atomically swaps their identity binding. The user notices nothing; afterward their Identity History shows the old binding (Inactive, reason: Tenant Migration) alongside the new active one.

Things to know:

• Stage before the user signs in from the new tenant. A sign-in from the new tenant without a staged migration is refused — Wayd never links an account by email alone — so stage it and have them sign in again. Only a sign-in whose username matches no existing account creates a new one, which can't be merged back without manual database work.
• Tenant migration is Microsoft Entra ID only. For moving a user between different OIDC providers, use Change Identity Provider instead.
• The selectable list excludes users who already have a migration pending. To retarget such a user, cancel their pending migration first (below).
• The Active Migrations section is read-only. To cancel a single user's pending migration, open that user's detail page (Settings → Access → Users → [user]) and pick Cancel Pending Migration from the Actions menu. There is no bulk-cancel.

Change Identity Provider

Moves a user from one OIDC provider to another, or from a local (Wayd) account to an OIDC provider. Like tenant migration, the change is deferred — the user's current login continues to work until they sign in via the target provider for the first time, at which point the rebind happens automatically.

This action is available for any user (including local accounts) when at least one enabled OIDC provider is configured that differs from their current one.

Workflow:

1. On the user detail page, open the Actions menu and pick Change Identity Provider (or Replace Pending Provider Migration if one is already staged).
2. Select the target provider from the dropdown of enabled OIDC providers and confirm.
3. The user's current login continues to work as normal.
4. When the user next signs in via the target provider, Wayd matches them by email, atomically deactivates their old identity, inserts the new one, and updates their login provider. The user notices nothing.
5. The Identity History grid on the user's page records the old binding as Inactive (reason: Provider Relinked).

Things to know:

• Stage before the user signs in via the new provider (Entra targets only). If the target provider is Microsoft Entra ID and the user signs in there before staging, Wayd creates a new account — there's no in-app merge path. For GenericOidc targets (Google, Okta, Auth0, Keycloak, etc.) this is not a risk: unknown users are rejected at the token-exchange boundary until a migration is staged for them.
• For users migrating from a local account: their password hash is cleared when the rebind completes, since the Wayd identity is deactivated. If the migration needs to be reversed, use Convert to Local Account.
• The action is hidden when only one OIDC provider is configured, or when the user is already on the only available provider.
• Re-staging with a different target provider silently replaces the previous one. Cancellation is available and idempotent.

Convert to Local Account

Converts an OIDC user to a local (password-based) account immediately — no deferred rebind. The admin sets a temporary password; the user is required to change it on their next login.

Workflow:

1. On the user detail page, open the Actions menu and pick Convert to Local Account.
2. Enter and confirm a temporary password, then confirm the action.
3. The user's OIDC identity is immediately deactivated and replaced with a local Wayd identity. Their next login must use the temporary password and they will be prompted to set a new one.

Things to know:

• This action is immediate and cannot be undone via the UI. To move the user back to OIDC, use Change Identity Provider to stage a new deferred migration.
• The user's UserId, permissions, and all other records are preserved — only the authentication method changes.
• The temporary password must meet the deployment's password policy (minimum 8 characters).

Identity Providers

Single sign-on providers are configured in Settings → Access → Identity Providers, which needs Permissions.OidcProviders.View (and .Create, .Update or .Delete to change them). A provider is either Microsoft Entra ID or Generic OIDC (Google, Okta, Auth0, Keycloak and the like), chosen when it is created. Beyond the connection details — Authority, Client ID, Audience, Scopes, Clock Skew (seconds), Enabled, and (for Microsoft Entra ID) the Allowed Tenant IDs — each provider carries a registration policy that controls whether and how new users are created when someone signs in for the first time.

Registration policy fields:

• Allow automatic user registration — The master switch. Off by default. When off, a person who authenticates successfully but has no Wayd account yet is turned away, and an administrator must create their account first. When on, a matching account is created automatically on first sign-in (subject to the options below).
• Require matching employee record — Shown only when auto-registration is on; defaults to on. While on, only people whose email matches an existing employee can self-register. Turning it off is a deliberate loosening — anyone who can authenticate through this provider will be granted an account — so the form shows a warning when you do.
• Default role for new users — Shown only when auto-registration is on, where it is required. The role assigned to accounts created through this provider — pick any role, system or custom. There is no implicit fallback; you must choose one explicitly.

What happens on first sign-in:

Auto-registration	Employee record	Result
Off	—	Sign-in rejected; an admin must pre-create the account.
On	Required, no match	Sign-in rejected ("restricted to users with an employee record").
On	Required, match found	Account created, assigned the default role.
On	Not required	Account created for anyone who authenticates, assigned the default role.

Things to know:

• The registration policy applies to Microsoft Entra ID providers. A Generic OIDC provider never creates an account at sign-in: someone signing in through it must already have an account whose move to that provider was staged with Change Identity Provider, and is otherwise refused.
• The first user is special. The very first person to sign in to a brand-new deployment always becomes an administrator, regardless of policy — this can't lock you out of an empty system.
• An existing account is never adopted automatically. Someone whose email matches an account already in Wayd is refused rather than linked to it, whatever the policy says, because an email alone doesn't prove who they are. Link them deliberately with Set Sign-in Tenant, Change Identity Provider, or tenant migration, depending on the account.
• Upgrades are secure by default. Existing providers have auto-registration turned off after upgrading to this version; re-enable it deliberately per provider.
• A role in use can't be deleted. If a role is set as a provider's default, attempting to delete it is blocked with a clear message until you repoint the provider to a different role.

Test, in the provider list and in the Discovery card on the provider's page, fetches the provider's OIDC discovery document from its authority and reports whether it was reached. A disabled provider is not offered at sign-in and its sign-ins are refused; its page says it is disabled.

A provider's detail page carries an Activity section: the provider added, its login label edited, its configuration (issuer, client, audience, scopes, allowed tenants or clock skew) changed, its registration policy changed, enabled, disabled or deleted — each entry with the values before and after. A provider stores no secret, so none is ever recorded.

Roles

Roles define permission groups. Users are assigned to roles to control access to features, pages, and actions throughout the application.

Permissions are named Permissions.\{Resource\}.\{Action\} — for example Permissions.Projects.Update. See Permissions for every permission and what it gates.

Managing roles, from Settings → Access → Roles:

1. Create Role gives a role a Name and Description; Copy Permissions From starts it with another role's permissions
2. A role's page has two sections. Permissions lists what the role holds, grouped by category and resource; Manage Permissions switches it to editing, with a switch per permission, Toggle All per resource and Select All, saved with Save Permissions. Users lists the role's members; Manage Users changes them
3. Edit changes the name and description; Delete removes the role

Things to know:

• The seeded Admin role holds every permission and cannot be edited, deleted, or have its permissions changed. A permission added to Wayd is granted to it automatically on startup.
• A role in use can't be deleted — not while users hold it, and not while it is an identity provider's default role.
• Viewing roles needs Permissions.Roles.View; creating, editing and deleting them need Permissions.Roles.Create, .Update and .Delete. Changing who holds a role needs Permissions.UserRoles.Update.

PPM requires more than a permission

In Project Portfolio Management, a permission claim alone is not enough to change a project, program, or portfolio — you must also lead the record as an Owner or Manager. See Permissions for the full rule.

Personal Access Tokens

Users can generate Personal Access Tokens (PATs) for API access. Each user manages their own on the PATs tab of their Account page: a token has a name (up to 100 characters) and an expiration date between one day and two years away (one year by default), is shown once at creation, and can be edited, revoked or deleted afterward. A token acts with the permissions of the user who owns it. See Your Profile. Every change to a token is recorded in the owning user's Activity, which administrators read from the user's detail page.

Feature Management

Wayd uses feature flags to control the visibility of features across the application. Feature flags allow new functionality to be deployed but hidden until ready for use.

How Feature Flags Work

1. Flags are defined in code by developers
2. On application startup, new flags are automatically seeded into the database, disabled unless the flag is defined to start enabled. Seeding only sets a flag's initial state; your enable/disable choices are preserved across updates
3. Administrators enable or disable flags through the Settings UI
4. The application checks flag state to show or hide features

Managing Feature Flags

1. Navigate to Settings > System > Feature Flags
2. View all available feature flags with their Name, Display Name, Type and whether each is Enabled; select a flag to see its description
3. From a flag's row menu, Enable or Disable it, or Edit its display name and description
4. Archive removes a flag you no longer need, and disables it. It is offered only for User flags — System flags are defined by Wayd and cannot be archived. Include Archived shows archived flags again

Viewing flags needs Permissions.FeatureFlags.View; enabling, disabling and editing need Permissions.FeatureFlags.Update, and archiving needs Permissions.FeatureFlags.Delete.

The flags Wayd defines:

Flag	Name	What it controls
Planning Poker	planning-poker	The Planning Poker feature, including Settings → Planning → Estimation Scales
Story Maps	story-maps	The Story Maps feature
Product Management	product-management	The Product Management module, including Settings → Product Management
Delivery Forecasting	delivery-forecasting	Monte Carlo delivery forecasts
MCP Server	mcp-server	The hosted MCP endpoint (/mcp) that exposes the API as agent tools
Team Capacity Management	team-capacity-management	Employee allocation to teams and team capacity planning

Feature flags gate both backend API endpoints and frontend UI elements. When a flag is disabled:

• API endpoints return 404 or are unavailable
• UI pages and menu items are hidden
• Related functionality is completely inaccessible

System Settings

System settings are organization-wide defaults. Until an administrator saves a section, every value in it is the default Wayd ships with. Viewing them requires Permissions.SystemSettings.View, and changing them requires Permissions.SystemSettings.Update.

Scheduling

Navigate to Settings > System > Scheduling to set:

• Default time zone — the time zone new team operating models start with (default UTC). Only IANA time zones are accepted, such as America/Chicago or Europe/London; the list shows each zone's current offset from UTC.
• Default commitment grace period (days) — how long after a sprint's planned start its commitment is taken when the team does not start the sprint itself (default 1, the end of the first planned day; 0 to 14).
• Default working days — the days of the week new team operating models work (default Monday to Friday; at least one).
• Default holiday calendar — the holiday calendar of every team operating model that names none of its own (default none: no holidays).
• Working day hours — how long a working day is (default 8; 1 to 24). It is the length of a person-day of capacity and the working day of everyone who has none of their own; a part-timer can be given a working day of their own on their employee page. Capacity plans can be read in hours, and team days off entered in hours are a share of it. It is the same for every team. Changing it changes the share of a person-day that anyone with their own working day is worth, past sprints included.

The time zone, grace period and working days are defaults only. They pre-fill new team operating models, and changing them does not change any existing team. The default holiday calendar is different: it is read, not copied, so changing it changes the holidays of every team that uses the default, including in past sprints.

Every change is recorded in the page's Activity section, with who made it and the values before and after.

Sprint Metrics

Navigate to Settings > System > Sprint Metrics to set:

• Sprint window (sprints) — how many of a team's most recent completed standard sprints its velocity, predictability and say/do are averaged over (default 7; 3 to 12).

The window is the same for every team, so their figures compare. It is read, not copied: changing it changes every team's figures the next time they are read.

Every change is recorded in the page's Activity section, with who made it and the value before and after.

Organization Settings

Holiday Calendars

A Holiday Calendar is a named set of days off, such as a country's public holidays. A team's operating model points at one, or uses the default calendar from the scheduling settings. A sprint's ideal burn-down line stays flat on the team's holidays.

A team's calendar holds only the days the whole team is off. A calendar is not tied to a team, so teams that share their days off share a calendar. A team spread across regions uses a calendar of the holidays its members share: a regional holiday that takes only some members out does not stop the team, which still burns, just more slowly.

With Team Capacity Management turned on, each person follows a calendar too: the one assigned to them for where they work, such as their country's, or otherwise the system default. Their team's calendar does not decide their holidays (see Time Away and Holiday Calendars). A holiday only some of a team's people take then lowers the team's capacity that day, and the ideal burn-down line drops by less, in proportion to who is there. Because people follow the system default unless assigned another calendar, set a default: the Holiday Calendars page warns when none is set.

Managing calendars:

1. Navigate to Settings > Organization > Holiday Calendars
2. Use Create Holiday Calendar and give it a unique Name and, optionally, a Description
3. Open the calendar and use Add Holiday to add a Date and Name for each day off. A calendar holds at most one holiday per date. Edit or remove a holiday from its row menu
4. Delete a calendar, with its holidays, from the row menu or the calendar's actions. A calendar a team operating model or an employee uses, or the default calendar, cannot be deleted. The calendar's page counts both

The calendar's Activity section records its creation, changes to its name or description, and every holiday added, changed or removed, with who made the change.

Viewing calendars requires Permissions.HolidayCalendars.View; creating, updating (including adding, changing and removing holidays) and deleting them require Permissions.HolidayCalendars.Create, .Update and .Delete. Choosing a team's calendar on its operating model also needs Permissions.HolidayCalendars.View, to list the calendars.

Team Member Roles

Team Member Roles define the roles that employees can hold when assigned to a team (e.g., Tech Lead, Engineer, Scrum Master, QA). Each organization defines its own set of roles.

Roles have:

• Name — A unique name (up to 128 characters)
• Active — Whether the role is available for assignment
• Counts toward delivery capacity — Whether time allocated to a team in this role adds to the team's delivery capacity. On by default. Turn it off for a role, such as a manager's, whose time on a team does not burn the team's planned work; that time still counts toward the person's 100%. Shown when Team Capacity Management is turned on

Managing roles:

1. Navigate to Settings > Organization > Team Member Roles
2. Use Create Team Member Role to add new roles
3. Edit a role's name from the row menu
4. Deactivate a role to prevent it from being assigned to new members (existing assignments are unaffected)
5. Delete a role — only possible if no team members are currently assigned to it and no allocation uses it

Work Management Settings

Work Types

Work Types define the categories of work items available in the system (e.g., Epic, Feature, User Story, Task, Bug). See Work Management for details on how work types are used.

Work Statuses

Work Statuses represent the states within a workflow (e.g., New, Active, Resolved, Closed). Each workflow places each of its statuses in a Work Status Category, which normalizes statuses across workflows, so the same status can sit in different categories in different workflows:

Category	Purpose
Proposed	Work has been proposed but not started
Active	Work is currently being performed
Done	Work has been completed
Removed	Work has been removed without completion

Work Processes

Work Processes define the configuration of work types, workflows, and hierarchies used within workspaces. See Work Management for details.

Product Management Settings

This area is behind the product-management feature flag.

Product Tags

Product Tags administers the axes products are labelled along — Platform, Tech Stack, Compliance — and the tags on each. Configured in Settings → Product Management → Product Tags. See Products for how a product is then tagged.

A tag category is one axis of classification:

• Name and Description
• Allows Many — whether a product can carry several tags from this axis. Chosen at creation and fixed afterward: narrowing it later would leave products holding more tags than the axis permits.
• Order — where the axis sits when the axes are presented, shown as a column. Presentation only, and not a field on the forms: drag a row by its grab handle to move it. A new axis lands at the end.
• Active — whether products can still be tagged along this axis.
• System — platform-seeded axes are read-only. They can be deactivated and repositioned, but never edited, deleted, or have their tags changed; an organization wanting different axes adds its own.

Open a category to manage its tags. Tags are managed through their axis rather than as a list of their own, because the rule they can break — no two tags on one axis sharing a name — belongs to the axis.

Tags themselves carry no order — they display alphabetically wherever they appear, in the settings grid and in the tag picker alike.

Things to know:

• Renaming a tag is safe. Products reference tags by id, so the new name shows on every tagged product at once — which is the point of a curated list over free text.
• Deactivating retires rather than removes. A deactivated tag or category can no longer be applied to anything new, but products already carrying it keep their tags, so what was recorded stays true. The tag list shows how many products carry each tag, so you can see what a change would affect before making it.
• Deleting is only for what nothing uses. A category that products are tagged along, or a tag that any product carries, cannot be deleted — deactivate it instead. A tag's Delete action only appears while its product count is zero.
• Reordering needs a clean grid. The grab handle is disabled while the list is sorted, filtered or searched, because the order on screen is not the stored order then and a drop would write a sequence you never saw. Clear all three and the handle comes back. A move saves the whole list at once, so the positions can never overlap.

To do this	You need
Open the page	Permissions.ProductTagCategories.View
Create a category	Permissions.ProductTagCategories.Create
Edit a category, activate or deactivate it, add or change its tags	Permissions.ProductTagCategories.Update
Delete a category or a tag	Permissions.ProductTagCategories.Delete

PPM Settings

Expenditure Categories

Expenditure Categories classify project spending for financial tracking and reporting. Categories have:

• Name and Description
• Capitalizable flag — Whether the expenditure can be capitalized
• Requires Depreciation flag — Whether depreciation tracking is needed
• Accounting Code — Code for integration with accounting systems
• State — Proposed, Active, or Archived

Project Lifecycles

Project Lifecycles define the template of stages that projects go through. See Project Portfolio Management for details.

Scoring Models

Scoring Models define formula-driven ways to score and rank work consistently — for example, prioritizing a backlog or portfolio projects by WSJF. Each model combines rated criteria with named output formulas, designating one as the primary score, and includes a Test report for previewing results without saving. Active models can be assigned to PPM portfolios. See Scoring Models for the full guide. Configured in Settings → PPM → Scoring Models.

Status Workflows

Status Workflows define the statuses each kind of record moves through — products, releases, release packages and deployments. A status carries a category for rollups and an optional alias giving it a well-known meaning, so Wayd's own logic keeps working whatever your organization calls each stage. Published workflows are immutable: change one by cloning it, editing the draft, publishing, and reassigning the record type — which brings every existing record across through a reviewed mapping. See Status Workflows for the full guide. Configured in Settings → System → Status Workflows.

Imports

Imports is where CSV files are imported from the app — choose the kind of import, check its columns, download a template, and submit the file — and it shows every CSV import file that has been submitted, what became of each row, and what you can still do about a run that did not finish — stop one that is going, resume one that stopped partway, or retry the rows it rejected once the underlying problem is fixed. Every file is applied by a background worker; submitting waits a few seconds for it, so a small file comes back finished while a large one comes back still running, and each run has its own page here where it is followed. Files submitted together — a wayd-data seed, an export split to fit the row cap — show as one batch with summed counts. You see the import types you are allowed to submit, and View Imports additionally grants read-only oversight of every type. See Imports for the full guide. Found in Settings → System → Imports.

Integrations

Wayd integrates with external systems to synchronize data. Integrations are configured through Connections.

Ownership Model

When data is synchronized from an external system, the objects created in Wayd have a Managed ownership. This distinguishes them from objects owned by Wayd:

• Owned — The object is managed within Wayd.
• Managed — The object is owned by an external system and is read-only in Wayd. Changes must be made in the source system and will be reflected in Wayd on the next sync.

Workspaces, work processes, workflows and work items are only ever created by a sync, so in practice they are managed.

Managed objects can still be associated or linked to owned items. For example, a work item synced from Azure DevOps (managed in Wayd) can be linked to a team objective owned by Wayd.

The ownership model applies to workspaces, work items, work processes, workflows, and sprints.

Connections

A Connection represents a configured integration with an external application via a Wayd Connector. Each connection includes authentication and endpoint configuration needed to establish the link. Connections are managed in Settings → System → Connections; Create Connection starts one, and Include Disabled lists inactive ones too.

A Connector is a configurable integration type that lets a specific external service plug into Wayd. What a connector can do is its capability, grouped under Work Management (work items), People (employees) or AI Provider, and it decides how Wayd uses the connection. Multiple connections for the same connector type can be configured — for example, when an organization has multiple Azure DevOps instances, or multiple Entra tenants after an acquisition.

Common actions on a connection:

• Edit — Update name, description, settings or credentials. A secret field starts empty, marked Unchanged: leave it empty to keep the stored value, or type a new one to replace it. A stored secret is never shown again.
• Activate / Deactivate — Toggle whether the connection participates in sync runs. A new connection starts active. Inactive connections are excluded from every scheduled and manual sync — the API rejects sync attempts on an inactive connection.
• Delete — Removes the connection. Past sync history rows are preserved by design.

Sections of a connection's page: Overview (its settings, with secrets masked), then what its connector adds — Organization Configuration and People for Azure DevOps — then Sync History for a connector that syncs, and Activity.

• Sync History — Past runs with their status, duration and per-run details (workspaces, work items and work item revisions for work sync; employees fetched, upserted and excluded, and any per-record errors, for people sync), over the last 24 hours, 7 days or 30 days. Its Diff Sync and Full Sync buttons run a sync of this connection alone; they are disabled while the connection is inactive.
• Activity — Records the connection created, its name or description edited, its settings changed (each entry lists the settings before and after), its credentials replaced, activated, deactivated or deleted, and by whom. A credential change records which credential was replaced — the personal access token, API key, client secret or password — and never its value, not even hashed. Syncing workspaces, processes and teams from Azure DevOps and probing a Workday configuration are not recorded here; the Sync History section covers them.

Only one people connection may be active at a time. Several Entra or Workday connections can exist — stage one, configure it, and activate it at cutover — but activating one while another is active is refused, and a people sync fails while two are active.

Nothing syncs on a schedule until you create one. Create a recurring Work or People sync job under Background Jobs.

Viewing connections needs Permissions.Connections.View; creating, changing and deleting them need Permissions.Connections.Create, .Update and .Delete.

The integrations reference covers each connector in depth.

Azure DevOps Boards

The Azure DevOps Boards connector enables one-way synchronization of work data from Azure DevOps into Wayd. Capability: Work Items. See Azure DevOps.

Data mapping:

Azure DevOps	Wayd
Project	Workspace
Work Item	Work Item
Work Item Type	Work Type
Area	Team ↔ Work Item association
Iteration	Sprint / Planning Interval association
Story Points, Effort, Size	Story Points, Effort, Size — each from its own field, whatever the process

Configuration requirements:

• Organization — The Azure DevOps organization name
• Personal Access Token — A PAT with Work Items (Read) and Project and Team (Read) scopes

Setting it up: after creating the connection, Sync Organization Configuration reads the organization's processes, projects and teams into the Organization Configuration section. Initialize a work process first, then set up each workspace's integration, then map its teams. Every sync also refreshes the organization configuration before it runs.

Business rules:

• Each Azure DevOps organization can only be linked by one connection
• Synchronized items have Managed ownership and are read-only in Wayd
• Sync is controlled by workspace-level integration state (active/inactive)
• The People section matches Azure DevOps identities to Wayd employees

Entra (Microsoft Entra ID)

The Entra connector synchronizes people from Microsoft Entra ID into Wayd's Employee records via Microsoft Graph. Capability: People. See Entra.

Capabilities:

• Pull member users from a single Entra tenant; guest accounts are not synced
• Optionally scope to a single Entra group (transitive members)
• Optionally include disabled accounts
• Upsert into Wayd Employee records, with each user's manager
• Deactivate Wayd employees no longer present in the latest payload

Configuration requirements:

• Tenant ID — The Entra tenant's directory ID
• Client ID — Application (client) ID of the Entra app registration used to authenticate
• Client Secret — Application client secret (encrypted at rest, masked on display)
• All Users Group Object ID — optional. When set, only users transitively in this group are synced. Leave blank to sync all member users in the tenant.
• Match Employees By — Email (default) or Employee Number: the employee field a synced user is matched on.
• Include Disabled Users — optional, default off. When on, disabled accounts are included.
• Normalize Name Casing — default on. Names that arrive in all capitals are title-cased; mixed-case names are kept as they are.

The Entra app registration needs the User.Read.All Microsoft Graph application permission (plus GroupMember.Read.All if you scope to a group). Both require admin consent. The credentials are not tested when the connection is saved; the first sync is what shows they work.

Business rules:

• Entra cannot fetch only what changed, so every run — differential or full — fetches the complete user set and reconciles against Employee.
• Employees not in the latest payload are automatically deactivated.
• Manager hierarchy is built from each user's Entra manager reference.

Workday

The Workday connector synchronizes workers (employees and contingent workers) from a Workday tenant into Wayd's Employee records through Workday's Staffing web service. Capability: People. See Workday.

Configuration:

• WSDL URL — The tenant's Staffing web service address
• ISU Username and ISU Password — The integration system user Wayd signs in as (the password is encrypted at rest)
• Worker Key — Which Workday identifier becomes the employee number (default Employee ID)
• Match Employees By — Email (default) or Employee Number
• Include Inactive Workers — default off
• Use User_ID as Email Fallback — default off. Uses the worker's Workday user id as their email when they have no work email
• Use Preferred Name — default off. Uses the worker's preferred name instead of their legal name
• Normalize Name Casing — default on
• Department Source — The Workday organization type an employee's department is read from (default supervisory organization)
• Worker exclusions — Set when editing the connection: workers in the chosen organizations are left out of the sync

Saving or editing the connection, and Test Connection on its page, probe the tenant with the given credentials and report what they can read. Workday supports differential sync, which fetches only workers changed since the last run.

AI Providers

The Azure OpenAI connector stores the details of an Azure OpenAI deployment. It doesn't sync data into Wayd, and no Wayd feature uses it yet. Capability: AI Provider. See Azure OpenAI.

Background Jobs

Wayd runs recurring and on-demand work — syncs, replication, maintenance — as background jobs. Settings → System → Background Jobs is where you watch and control them.

What the page shows

Counts are split into two rows, because they answer different questions:

• Current — jobs that exist right now. Each tile agrees with the matching tab: Processing, Enqueued, Scheduled, Failed, Succeeded, plus Recurring schedules and Servers. Retries (jobs waiting out a retry delay, also counted under Scheduled) and Awaiting (continuations held until the job they depend on finishes) appear when the scheduler reports them.
• All time — running totals of everything that has ever succeeded or been deleted. These keep climbing after the job records themselves are purged, so they are normally far higher than the Current figures.

Succeeded appears in both rows, with different meanings

Succeeded jobs are retained only briefly before being purged. Current → Succeeded counts the ones still on record — often a handful, or none. All time → Succeeded counts every job that has ever completed. A large gap between them is expected, not a fault.

Three tabs sit below the tiles:

Tab	What it is for
Jobs	Browse jobs by state — Processing, Scheduled, Enqueued, Failed, Succeeded, Deleted. Select a job to open its detail panel.
Recurring	Every registered schedule, with its cron expression, next and last run, and the outcome of the last run. Remove a schedule here.
Servers	The worker processes polling for jobs, with their heartbeat. No servers means nothing will run.

Diagnosing a failure

Open the Failed state on the Jobs tab and select the job. The detail panel carries the exception type and message, the full stack trace, the arguments the job ran with, and its state history — every transition and why.

From there you can Requeue the job to try again, or Delete it.

Running and scheduling jobs

Actions offers every job type for an immediate run, grouped as Integration Jobs, Data Replication Jobs and Maintenance Jobs. The job types are:

• Work Full Sync and Work Differential Sync — Synchronize work data from every active work-management connection (Azure DevOps). Differential fetches only items changed since the last sync. A failed run is retried up to three times.
• People Full Sync and People Differential Sync — Synchronize people from the active people connection (Entra or Workday). A connector that cannot fetch only changes, such as Entra, runs a differential sync as a full one. A failed run is not retried: fix the cause and run it again. The run fails when more than one people connection is active.
• Projects Sync, Teams Sync, Iterations Sync, and Strategic Themes Sync — Replicate their respective records across domains.
• Portfolio Rank Rebalance — Maintenance job that re-spaces dense project ranks within portfolios after repeated drag-to-rank operations.
• Import Stall Recovery — Ends an import whose worker stopped responding and republishes one whose run never started. Scheduled every five minutes by default as import-stall-recovery; the schedule can be changed, and a deleted one is restored the next time the server starts. See Imports.
• Import Retention Sweep — Discards the stored copy of each row once an import is past its 30-day retention window. Scheduled nightly by default as import-retention-sweep; like the stall sweep, the schedule can be changed and a deleted one is restored the next time the server starts. See Imports.

Create Recurring Job schedules a job with a cron expression. It offers only the job types that can run on a schedule — the cross-domain replication syncs (Projects, Teams, Iterations, Strategic Themes) are driven by the changes that trigger them, so they are available to run on demand but not to schedule. No sync is scheduled out of the box: to sync connections on a timetable, create a recurring Work or People sync job here.

With Permissions.Hangfire.View, Actions also links to the Hangfire Dashboard, the scheduler's own console.

Permissions

To do this	You need
Open the page and browse jobs	Permissions.BackgroundJobs.View
Run a job, create a schedule, requeue a job	Permissions.BackgroundJobs.Run
Delete a job or remove a recurring schedule	Permissions.BackgroundJobs.Delete
Open the Hangfire Dashboard	Permissions.Hangfire.View

Messaging

Wayd hands much of its internal work — keeping one area's records in step with another's, applying imports — to messages that are delivered and processed in the background. Settings → System → Messaging shows the state of that delivery and holds the messages that could not be processed.

What the page shows

Tile	What it counts
Incoming	Messages saved and waiting to be processed. It rises only when delivery backs up — a burst of messages, database latency, or messages recovered after an unclean shutdown. Zero is the healthy state.
Scheduled	Messages due at a later time — mostly failed messages waiting out a retry delay (1, 5 and 15 seconds between attempts) before they either succeed or become dead letters.
Outbox	Outgoing messages saved with a change but not yet sent. Zero is the healthy state.
Dead Letters	Messages that failed every retry. These stay until you replay or discard them — this is the tile to watch.
Handled	Processed messages kept for five minutes to detect duplicates, then removed. Usually zero; it is not a history of past work.

Below the tiles, the dead letter grid lists each failed message with its Message Type, Exception Type, Exception Message, Sent At, Attempts, whether it is Queued for Replay, and its Queue. Select a message type to open its details, including where it came from, its correlation id and the message body. The grid shows up to 500 messages and says how many more there are.

Replaying and discarding

From a message's row menu:

• Replay queues the message to be processed again. It returns to the incoming queue on the next pass, so it can take a moment to leave the list. Replay once the cause of the failure is fixed.
• Discard permanently deletes the message, after confirmation. Whatever it would have done is never done.

To do this	You need
Open the page	Permissions.Messaging.View
Replay a dead letter	Permissions.Messaging.Run
Discard a dead letter	Permissions.Messaging.Delete

Estimation Scales

This feature is behind the planning-poker feature flag.

Estimation Scales define the sets of values used for story point estimation in Planning Poker sessions. Scales are configured in Settings > Planning > Estimation Scales.