Migration Guide: Moving to the New Dashboard Sign-In

Dashboard is moving from the legacy login and roles to a new sign-in with role-based access control (RBAC). Each organization moves on its own schedule, agreed with your Incode representative. Everyone keeps the access they have today, and your administrator reviews roles after migration. When your organization's end date passes, the legacy login stops working.

At a glance

What is changing

Key concepts

• Migration window: The period when both the legacy login and the new sign-in work. It starts when your Incode representative turns on the new sign-in for your organization and ends on your end date.
• End date: The date the legacy login stops working for your organization. You agree on it with your Incode representative, and it is never later than 31 March 2027. A shorter window means less time keeping the two sides in step.
• Migrated role: A role created from a user's legacy access and named after it: for example, "Admin Legacy Role". Migrated roles are created in your organization, and you can edit them like custom roles. For details, refer to How legacy access maps to roles.
• Service account: A legacy Dashboard user that one of your integrations depends on. Service accounts are not tied to a person accessing Dashboard. They are never migrated, and they keep working through the API after your end date. For details, refer to Scenario 1.

Migration steps

Every organization follows the same steps. Which steps apply to you and what your administrator does in them depend on your scenario.

Enforcement

Every organization must have an end date. On your selected end date:

• Users who haven't been migrated cannot sign in. Your administrator can still migrate them afterward, and they then sign in at your new Dashboard address.
• Service accounts keep working through the API, but cannot sign in to Dashboard using the legacy login.
• There is no way back to the legacy login.

Your Incode representative can change your end date at any time before it passes. The new date can be earlier or later, but no earlier than the next day.

Find your scenario

Identify every scenario that applies to your organization. Every organization follows either Scenario 2 or Scenario 3, depending on how your team signs in. If an integration signs in as a Dashboard user, Scenario 1 also applies.

Scenario 1: Integrations that use a Dashboard user

Applies when: a backend-to-backend integration authenticates as a Dashboard user using the legacy login. For example, it calls /executive/log-in with a user's email and password to get an admin token.

What to do instead: have the user marked as a service account before your end date. Service accounts are never migrated, and they keep signing in through the API after your end date. Without this, the integration’s /executive/log-in calls start failing on your end date.

Prerequisites:

• A list of the legacy Dashboard users your integrations depend on.

What the change looks like

1. Give your Incode representative the list of users your integrations depend on. Do this early: ideally, before your administrator migrates anyone.
2. Your Incode representative marks each one as a service account. Marked users appear on the Service Accounts tab of the Users page in Dashboard. A user can be marked at any time before your end date.
3. The integration keeps signing in through the API, during the migration window and after your end date. Existing API keys keep working.

If a user was marked as a service account by mistake, your Incode representative or an administrator with the Access Manager role can switch it back to a regular user, and it can then be migrated. On the Users page, open the user’s row menu and click Turn into regular user. Likewise, if a user you meant to mark as a service account was already migrated, it can still be marked. Make either change before your end date, because the Users page may no longer be available after it.

After migration: Check your integrations

After your end date, a service account cannot sign in to Dashboard using the legacy login. Check that no one on your team relies on signing in as a service account to use Dashboard. Give those people their own users and roles in the new sign-in instead.

Scenario 2: Teams that sign in with a password

Applies when: your team signs in to Dashboard with a username and password.

What to do instead: your administrator migrates each user to the new sign-in. Each user then accepts an emailed invitation, enters a one-time code, sets a new password, and signs in at your new Dashboard address. Passwords cannot be carried over, so every user must do this.

Prerequisites:

• Your end date, Dashboard address, and first administrator agreed with your Incode representative.
• Your first administrator migrated, with the roles to manage users. Your Incode representative does this.

What the change looks like

1. Your Incode representative migrates your first administrator. They keep their current access as migrated roles. Your Incode representative also gives them the Access Manager and Configuration Manager roles, because migrated roles never include managing users or organization setup. Without these, your administrator cannot migrate anyone.
2. Your administrator migrates everyone else. On the Users page in Dashboard (not the Users tab in Organization), signed in with the new sign-in, they can migrate users one at a time, migrate a selection, or click Migrate all users. Each user's status updates as they move. For details, refer to Migration statuses.

3. Each user accepts their invitation. They receive an email titled "Get access to your Incode Dashboard" and click Set up your account. They enter the one-time code sent to their email, set a password, and sign in at your new Dashboard address. The invitation link lasts 48 hours and works once. If it expires, they click Send me a new link.
4. Optional: Your administrator sets up two-factor authentication after everyone is migrated.

The one-time code in the invitation only confirms the user's email address. It doesn't turn on two-factor authentication, which is a separate organization setting.

Who gets migrated

• Users blocked from Dashboard via the legacy login are migrated too, but arrive deactivated and don't get an invitation. To leave someone out, migrate a selection instead of everyone.
• Incode staff in your organization aren't migrated. Their status shows as Not migratable.
• Service accounts aren't migrated. For details, refer to Scenario 1.

After migration: Review roles

Every migrated user starts with migrated roles that match their legacy access. Your administrator can keep them, edit them like custom roles, or move users to default roles.

Check these in particular:

• Users with Limited Visibility can now export sessions. Migrated roles include session export. To keep the old restriction, give these users a role without sessions:export. For details, refer to Limited Visibility.
• Users with no role can sign in but cannot do anything. Assign them a role.

Scenario 3: Teams that sign in through an identity provider

Applies when: your team signs in to Dashboard with their company account through an identity provider, such as Okta or Microsoft Entra.

What to do instead: create a new app for Incode in your identity provider, then connect it to Dashboard by setting up company sign-in on the Setup tab. Your existing app stays active, so the legacy login keeps working until your end date. Users then sign in at your new Dashboard address and keep their migrated access.

Prerequisites:

• Your end date, Dashboard address, and first administrator agreed with your Incode representative.
• Someone who can configure your identity provider.
• A decision on where roles will come from. For details, refer to Choose how users and roles are kept updated.
• Your first administrator migrated, with the roles to manage users and organization setup. Your Incode representative does this.

Choose how users and roles are kept updated

The migration steps are the same for every identity provider setup. What differs is who keeps users and roles updated afterward.

What the change looks like

1. Your Incode representative migrates your first administrator and gives them the Access Manager and Configuration Manager roles. Without Configuration Manager, your administrator cannot set up company sign-in.
2. Create a new app for Incode in your identity provider, and assign your users to it. Keep your existing app active, so the legacy login keeps working during the migration window.
3. Your administrator sets up company sign-in with OIDC or SAML, on the Setup tab of the Organization page.
4. If roles will come from user sync, your administrator maps each group to a role on the Groups tab before switching where roles come from.
5. Your administrator migrates everyone else, as in Scenario 2, step 2.
6. Each user signs in at your new Dashboard address. They don't get an invitation email. Their first sign-in links them to their migrated user, so they keep their migrated roles. Share the new address with your team.

Users must be assigned to the new Incode app in your identity provider to sign in. Users who were never migrated are created the first time they sign in. What they can do depends on where roles come from:

• Manual: They can sign in, but cannot do anything until your administrator assigns them a role.
• SCIM, IdP groups claim, or IAM roles claim: They get the roles set up for them in your identity provider.

After migration: Review roles and remove the old app

1. Review roles, as in Scenario 2.
2. After your end date, remove the old Incode app from your identity provider. It no longer does anything.

During the migration window

Your organization's users exist in Dashboard via both the legacy login and the new sign-in, and changes don't carry over from one to the other.

To avoid gaps, add new users in the new sign-in, and when someone leaves, remove them on both sides.

Migration statuses

When you’re signed in to Dashboard with the new sign-in, the Users page in the left menu shows each user’s migration status. The Users tab in Organization doesn’t show these statuses.

How legacy access maps to roles

Each legacy role becomes one migrated role, named after it, with a fixed set of permissions. No one is moved to a default role automatically. After migration, your administrator can move users to default roles.

Legacy permissions

Legacy permissions for the Executive with Custom Permissions role each become their own migrated role with the matching new permissions. Some are handled differently:

Limited Visibility

Limited Visibility in Dashboard via the legacy login does two things. Only one of them carries over:

• Limits sessions to a time range: Carries over as the user's Limited Visibility setting. The time range is still set once for the organization.
• Turns off CSV and PDF export: Doesn't carry over. To keep this restriction, give the user a role without sessions:export.

Own records only limits which records a user sees, not how old they are. It matches the legacy Executive role, not Limited Visibility.

Troubleshooting