Users and Entra sync

You manage accounts from Users (/admin/users). Owners and admins can change them; read-only admins can only view them.

How accounts are created

Frontdoor creates an account the first time someone signs in with Microsoft, using their Microsoft profile. To prepare accounts before that, use pre-onboarding.

Manage a user

From the users list you can search, change a user's role, activate or deactivate an account and delete it. Deleting a user also cleans up its related data.

Deactivated users cannot sign in until an admin reactivates them.

The owners listed in ADMIN_EMAILS are marked in the list and cannot be demoted from the web interface. Roles are described in Groups and access.

See the apps a user can reach

Open a user and select Visible apps: you see exactly which apps the user can open and through which group.

Pre-onboard users

Pre-onboarding creates the accounts of people who exist in Microsoft Entra but have not signed in to Frontdoor yet.

1. In Users, select Pre-onboard users.
2. Search Microsoft Entra by name or email and add the people you want, up to 50 at a time.
3. Optionally choose the Local groups they should join. The default group is always added.
4. Select Pre-onboard.

Each account is linked to its Entra user by object ID and is completed at the first sign-in. Entra groups are added by the next sync or at the first sign-in. When a pre-onboarded user signs in for the first time, admins get a notification.

Pre-onboarding needs the Microsoft Graph application permission User.Read.All (see Microsoft Entra setup), even when Entra group sync is off.

People who left the organization

When Sync groups runs and Microsoft Entra no longer knows a linked user (Microsoft Graph answers 404 Request_ResourceNotFound), Frontdoor deactivates that user and marks them Not found in Entra. Groups, preferences and access history are kept.

Use the status filter in Users to list them, then delete them for good or reactivate them. The mark is cleared when the user is found again or reactivated.

The owners in ADMIN_EMAILS and the last active administrator are only marked, never deactivated.

Act as a user

To see Frontdoor exactly as a user sees it, open the user's detail and choose Act as this user. Enter a Reason (up to 500 characters) and select Start. Owners, admins and read-only admins can do this.

• You can act only as active users with the user role, and never as yourself.
• The session is read-only: every change is refused (error code impersonation_read_only), and apps cannot be opened (impersonation_app_launch_blocked); no SSO token is ever issued.
• A banner on every page shows who you are acting as. Select Stop to return to your own account without signing in again.
• The session ends when you stop it, when you sign out, when your own session expires, or after IMPERSONATION_TIMEOUT_MINUTES (default 30 minutes).

Start, end, blocked changes and blocked app launches are written to the audit log with target type impersonation. See Logs, audit and retention. Ended sessions are purged together with the logs and left out of backups made with Leave out access and audit logs.

Avatars

Frontdoor shows Microsoft 365 profile photos, falls back to Gravatar, and finally to the person's initials. Microsoft 365 photos are fetched from Microsoft Graph when users sign in. Avatars are cached on disk (AVATAR_CACHE_DIR) and refreshed only after AVATAR_CACHE_TTL_DAYS (default 14), or AVATAR_CACHE_MISS_TTL_DAYS (default 30) when no photo was found, so pages do not call Graph on every load.

To prewarm the cache for existing users, an operator can run npm run avatars:prewarm (in Docker, see Install with Docker). Fetching Microsoft 365 photos for existing users needs the Graph permission ProfilePhoto.Read.All.

When someone changes a photo in Microsoft 365 and you want it to appear right away, owners can clear the avatar cache from Customize.

Notifications

Owners, admins and read-only admins see a bell in the top bar with the number of unread notifications. Frontdoor raises a notification when:

• a user is deactivated because they are no longer in Microsoft Entra
• an account created in advance signs in for the first time
• the Microsoft Entra sync fails, at sign-in or during a sync
• an imported Entra group is deleted in Microsoft Entra

Each notification links to the page where you handle it. Owners and admins can resolve them; some resolve on their own, for example when the user is reactivated. Resolved notifications are removed after NOTIFICATION_RETENTION_DAYS (default 30). The audit log keeps the history.