Runbooks/Admin Ui

IdentityMesh Admin UI

The Admin UI is the Angular-based administration portal for IdentityMesh. It’s installed by the MSI as an IIS site alongside the Admin API and is the primary operator interface — connector configuration, schedule management, role assignments, run history, and audit views.

Build

npm install
npx ng build --configuration production

Output: dist/now-ui-dashboard-pro-angular/

The production build produces hashed static files (JS bundles, CSS, assets) suitable for deployment to any web server.

Deployment

The Admin UI is a static single-page application (SPA). It must be served by a web server such as IIS, nginx, or any static file host.

MSI Install

When installed via the IdentityMesh MSI (AdminUI feature), files are placed in C:\Program Files\IdentityMesh\ui\. The installer automatically:

  1. Creates an IIS site (IdentityMesh Admin Portal) on the configured port (default 4200) if IIS is available.
  2. Writes assets/config.json with the API URL chosen during install (default https://localhost:5100).
  3. Creates a desktop shortcut to the Admin Portal.

Manual IIS Configuration

If IIS was not available during install, or for custom setups:

  1. Create a new IIS website pointing to C:\Program Files\IdentityMesh\ui\.
  2. Set the default document to index.html.
  3. The UI uses hash-based routing (/#/), so no URL rewrite rules are needed.
  4. Edit assets/config.json if the API is on a different server.

API URL Configuration

The UI loads its API URL at runtime from assets/config.json. This file is written automatically by the installer’s database step.

Runtime config (assets/config.json):

{
  "apiUrl": "https://localhost:5100"
}

If config.json is missing or has no apiUrl, the UI falls back to relative URLs (same-origin requests). The UI loads this file before it starts, so a change takes effect on the next full page load.

For separate-server deployments (UI and API on different machines), edit config.json to point to the remote API:

{
  "apiUrl": "http://api-server.domain.com:5100"
}

Authentication

The UI uses Windows Integrated Authentication (Negotiate). All API requests send the browser’s Windows credentials. The IIS site hosting the UI must have Windows Authentication enabled.

Features

The Admin UI provides management interfaces for:

The connector editor

Add connector on the Connectors page, and Edit on any connector row, open a full page rather than a pop-up. The page has a header with the connector’s name, a rail of sections on the left, the section you are working on in the middle, and a footer with Test connection, Discard and Save. Nothing is saved until you press Save (Create connector on a new connector), except schedules, which save as you change them. If you leave the page with unsaved changes, the console asks before discarding them.

If your role can read connectors but not change them, the page opens read-only and Save is hidden.

Choose a type and a name

A new connector opens on Type & name. The page shows one card per connector type:

Pick a card, then enter a Name. Under Run on, choose This server to run the connector on the IdentityMesh server, or one of the relay agents to run it there. The other sections stay locked until you pick a type. The type of an existing connector cannot be changed.

The rail

The rail on the left lists the sections for the connector’s type. Each entry shows a check mark when its section is complete, or a count of the open issues in it, such as a required field that is empty or a value that is not valid. Save stays disabled while there are open issues; hold the pointer over it to see which section is blocking. On a narrow screen the rail becomes a strip above the section.

The sections depend on the type:

TypeSections
Active DirectoryConnection, Partitions, Object types & attributes
Entra IDApp registration, Object types
OktaConnection
WorkdayConnection, Attributes & paths, Import
SQL ServerConnection, Tables & object types
FileFile & format
Custom connector that describes its settingsOne section for each section the connector declares, in the connector’s order, then Object types
Custom connector that does notConfiguration, where you edit the settings as JSON

Every type also has Type & name first, and Schedules and Advanced last.

A few of the sections need a word of explanation:

Test connection

Test connection sits at the left of the footer and shows its result beside it: a green sentence when the connector reached the source, a red one with the reason when it did not. While the form has open issues the footer says Fix the issues above to test instead. The button is not shown for a connector type that has no connection test. For Active Directory, Browse OUs and Discover attributes work for a connector that runs on the IdentityMesh server by connecting from that server, and for a connector on a relay agent by connecting from the agent.

Enabled

The Enabled switch in the header turns the connector on or off. You can change it before you create the connector and at any time after.

Save

Save checks the settings, then stores them. A connector that describes its settings is also asked to check them. If it rejects them, the page keeps you where you are and shows the connector’s message next to the field it concerns. A message that does not belong to any one field appears in a red box above the footer, headed The connector rejected this configuration. Correct the settings and press Save again. The page also refuses a configuration that is not a JSON object, naming the faulty path.

If the host that runs the connector cannot be reached, the page cannot ask the connector to check the settings. It shows the message it got and a Save without connector validation button. Pressing it saves the settings as they are. The save is written to the audit log as having skipped the connector’s own check, so you can see later which connectors were saved that way. Use it when you know the settings are right, and run Test connection once the host is back.

Discard puts the page back to the last saved values. On a new connector it returns you to the list.

What next

After Create connector succeeds, the page stays open on the new connector with a What next card above the sections:

Press Dismiss to hide the card.

Schedules

Schedules lists the connector’s run groups and intervals, and lets you add, edit, enable, disable and delete them. Each schedule has an import mode (Delta or Full), an interval in minutes and a run group. Schedule changes save immediately and are not part of the connector’s Save. On a new connector the section asks you to save the connector first.

Advanced

Advanced shows the connector’s whole configuration as JSON. It and the other sections are two views of the same settings: a change in one appears in the other as soon as the JSON is valid. Invalid JSON blocks Save and puts a count against Advanced in the rail, with the parser’s message under the box.

Secrets are never shown. After a save the configuration holds a reference to the stored secret, and a secret field shows a mask with a Change link. The stored value stays as it is unless you press Change and type a new one.

Settings → AI assistance

The Settings page has an AI assistance tab (visible with roles.read; changing it needs roles.write) for the optional AI features: suggested sync rules in the connector editor, and explanations of failed runs and drifted connectors. It needs an Enterprise license and is off until an administrator saves a provider and key with the master Enabled switch on, tests the provider, ticks the data agreement, then switches the features on in the Features card and saves again. Clear key deletes the stored key.

When it is on, the connector editor gains a Suggested rules entry in edit mode and a Suggest sync rules button, and failed runs gain an Explain button. See the AI assistance runbook for setup, the data sent, auditing and turning it off.

Settings → Email

The Settings page has an Email tab in the Integrations group (visible with roles.read; saving, clearing a secret and Send test need roles.write). It sets up how IdentityMesh sends email for self-service group notifications, the workflow Send email step and vault check-out approvals. Pick one provider (SMTP, Mailgun or Microsoft 365), fill in its card, switch Send email on and save. Secret fields show a mask when a secret is stored and are kept when left blank. Use Send test to check the saved settings. See the Email runbook for each provider’s setup.

Groups module

The /groups module is the end-user and administrator surface for self-service groups: owner-managed Active Directory and Entra ID groups provisioned through the ordinary export engine. It is new in this release; run the acceptance round trips in that runbook against your own directory before opening it to users.

PageWhoWhat it does
My Groupsowners (groups.own)Create a group within policy; edit, renew, restore, delete or leave it; manage members and co-owners.
Browse and Joineveryone with groups.readFind joinable groups and request to join. Open groups add you at once; owner-approval groups raise a request; closed groups refuse.
My Requestsgroups.requestYour own pending and decided join requests; cancel a pending one.
Approvalsowners and groups.adminDecide pending requests for groups you own. High-impact groups need a second decision from a different groups administrator.
Group Auditgroups.audit.readQuery the hash-chained group audit trail by group, user and date range; export it to CSV.
Configure → Groupsgroups.adminThe install-wide policy (creator groups, allowed types, naming, expiry caps, target OUs, connectors) and a link to Settings → Email for notifications.
Configure → Groups → Onboard existinggroups.adminBring groups that already exist in Active Directory under self-service management without recreating them: pick an AD connector, tick groups, Preview what the first export would change, set owners and policy for the batch, and confirm. See the onboarding section of the groups runbook.

Two things surprise first-time administrators. An empty creator-group list means only groups administrators can create, while an empty allowed-type list means all types are allowed. And a newly created group shows Pending until the provisioning sweep sees its directory link; if the export engine is paused it stays Pending, so check the export queue before assuming it failed.

Workflows

The /identity/workflows page (under Configure in the sidebar, needs workflows.read) lets Enterprise administrators build and operate mesh workflows: steps that run when an object enters or leaves a Composer group.

The workflow designer: a palette of steps on the left, a canvas with a trigger card, a webhook step and an If/else branch with Then and Else lanes in the middle, and the selected step's properties on the right

The workflow designer (preview rendering; some field names and expression syntax differ in the product)

TabWhat it does
WorkflowsLists each workflow with its trigger, whether it is enabled, its last run and its failed count. New workflow and Edit open a full-page designer. The palette on the left offers Add a step (group, set attributes, send email, call a webhook), Control (If/else) and Custom (it reads “None installed” until custom steps exist); drag an item onto the canvas or between the THEN and ELSE lanes of a branch. The canvas in the middle starts with a sentence card for the trigger, such as When an object enters "<rule>" or When department changes on Person, followed by a card for each step. The trigger’s properties start with a Kind switch, Composer rule or Attribute change. For an attribute change you pick an Object type and add the Attributes to watch as chips; the suggestions come from the attributes known for that type, and you can type a name that has not appeared yet. Below the trigger, a Loop guards section sets Max chain depth and Max runs per object per hour for this workflow. See Attribute-change trigger. Every connection has a + button that opens a menu, so the whole workflow can be built from the keyboard. Each card has a ⋯ menu with Rename, Duplicate, Move and Delete. You can zoom, and undo and redo with Ctrl+Z and Ctrl+Y. The properties panel on the right shows the selected step’s settings, with an Available values picker that lists the object’s attributes, workflow values and the outputs of earlier steps only. A status bar shows ✓ Valid or the number of issues, the step counts and the last run. Validate and Save mark any problem as a badge on the step that has it. The first time you save a workflow that calls a webhook, the signing secret is shown once. The header has Validate, Run now (against an object, after you confirm; an attribute-change workflow asks for the pretend old and new values) and Save buttons, and a ⋯ menu that holds Delete workflow. Rotate signing secret is in the properties panel, under a step that uses the signing secret such as the webhook step. See Branches and Step outputs.
RunsFilters by workflow, status, object and date. Opening a run shows the result of every attempt of every step, with Retry, Skip step and Cancel for users with workflows.execute. A banner offers Resume when workflows are paused, and another offers Release all or Cancel all for a workflow whose runs the burst guard held.

The Operations page shows a Workflows card, and a mesh object’s detail page lists that object’s workflow runs. Creating and editing need workflows.write, and the whole feature needs the Enterprise tier. Email steps send through the provider set under Settings → Email.

Notification bell

Every group decision, expiry warning, owner escalation and provisioning error is written to the recipient’s in-portal inbox, which the bell in the navbar opens. If email is set up under Settings → Email, the same notice is also sent by email, and the delivery outcome is recorded on the row. Reading the inbox needs groups.notify.read, which every built-in role has.

Inbox rows are purged after IdentityMesh:Retention:NotificationsDays (default 90), read or unread. The inbox is not an audit record; the Group Audit page is. See audit-retention.md.

Routing

The UI uses hash-based routing (useHash: true) for SPA compatibility without server-side URL rewriting. All routes are under /#/.

Authentication modes

The Admin UI supports two authentication modes, selected via the runtime config file assets/config.json:

ModeWhen to useHow the user signs in
negotiate (default)On-prem / domain-joined deployments behind IIS or a reverse proxy that handles Windows Integrated Authentication.Browser sends Kerberos / NTLM credentials transparently.
jwtCloud / hybrid deployments where the customer wants Entra-issued bearer tokens.MSAL redirect to Entra; user signs in with their Entra account.

Negotiate mode (default)

No additional configuration required. The Admin API requires authentication on every endpoint against the Negotiate scheme; the UI sends the browser’s Windows credentials with each request and the proxy handles SPNEGO.

JWT / Entra mode

In assets/config.json (a runtime-loaded file the UI reads on startup):

{
  "apiBaseUrl": "https://identitymesh-api.contoso.com",
  "auth": {
    "mode": "jwt",
    "tenantId": "<entra tenant guid>",
    "clientId": "<this-app's-Entra-app-registration-client-id>",
    "redirectUri": "https://identitymesh-ui.contoso.com/",
    "postLogoutRedirectUri": "https://identitymesh-ui.contoso.com/",
    "apiScope": "api://identitymesh-api/access_as_user",
    "multitenant": false
  }
}

Setup steps:

  1. Register a new app in Entra ID (separate from the Admin API app). Type: Single-page application. Redirect URI: the UI’s public URL (e.g. https://identitymesh-ui.contoso.com/).
  2. Under API permissions, grant delegated access to the IdentityMesh API app’s access_as_user (or equivalent) scope.
  3. Copy the Application (client) ID into auth.clientId.
  4. Set auth.mode to jwt and fill the rest of the block.

When auth.multitenant is true, the UI uses the common authority and Entra prompts users to choose their tenant. The API side must independently widen Authentication:Jwt:Authority or ValidateIssuer to accept multi-tenant tokens; until that happens, multi-tenant in the UI alone won’t pass API-side validation.

The UI automatically attaches the user’s access token to outbound calls to apiBaseUrl.

Switching modes

Mode is determined at startup. To change modes:

  1. Update assets/config.json on the deployed UI host.
  2. Hard-refresh the browser (or close + reopen the tab) so the updated config is fetched.

The Admin API can run with both schemes simultaneously (the SmartAuth policy scheme routes per request based on Authorization Bearer header presence). A site running JWT-mode UI will work against an API configured for either Negotiate or JWT (or both).

Localization (i18n)

The UI uses Angular’s built-in @angular/localize for translation. Phase 1 ships the build pipeline + a small set of representative strings extracted (sign-in flow, navbar). Most other strings remain hard-coded English; they are extracted progressively as features ship.

Supported locales

LocaleFile
en-US (source)src/locale/messages.xlf
fr-FRsrc/locale/messages.fr.xlf (stub — copy of source pending real translations)

Add additional locales by:

  1. Copying src/locale/messages.xlf to src/locale/messages.<locale>.xlf.
  2. Translating the <source> strings into <target> elements.
  3. Registering the locale in angular.json under projects.now-ui-dashboard-pro-angular.i18n.locales.

Building a localized bundle

npx ng build --configuration=production --localize

Produces a per-locale subdirectory under dist/now-ui-dashboard-pro-angular/ (one for en-US, one for fr-FR, etc.). Serve each locale from its own URL prefix via your web server’s URL rewriting rules.

Adding new translatable strings

Mark them in templates with the i18n attribute and a unique identifier:

<h2 i18n="@@dashboard.title">Dashboard</h2>
<button i18n="@@dashboard.refreshButton" aria-label="Refresh"
        i18n-aria-label="@@dashboard.refreshAriaLabel">
  Refresh
</button>

Re-run npx ng extract-i18n --output-path=src/locale --format=xlf to refresh messages.xlf. Translators add the new <trans-unit> entries to each per-locale file.