Account Owner - Understanding Portal Structure and Organization

This article reviews some general information on getting started with the Mursion portal including best practices on how to structure and organize your portal to get the most of Mursion.


Before we Begin

If you ever have any questions about any of the portal structures or any of the details below, always feel free to reach out to your Client Support Manager. And don't worry, either your CSM or an implementation associate will go over all of this with you as your project begins.

Portal Structure

Understanding how the portal is designed is essential in understanding your Mursion Mursion. It’s also good to think about this structure before proceeding with your implementation. 
  • Learners are organized into teams. 
  • Teams are assigned to scenarios.
  • Scenarios are individual simulations within a project. 
  • Projects are a group of scenarios with a common goal. 

Understanding the Different Ways Learners Can Connect to the Mursion Portal

Organizational size, security concerns, and administrative effort are all factors to consider when selecting a process for users to log into the Mursion Portal, though we do highly recommend that everyone implement an SSO configuration, if available. 

Note:  Choosing a connection method is a technical decision as well as an administrative decision. We recommend reviewing these options with your IT Team to understand what’s possible, and what structures may already be in place to facilitate these integrations. Account Owners should expect to have a testing period in the Mursion Portal staging environment prior to launch when using SSO. A more technical look at SSO can be found here.

Learners can connect with a Username and Password



  • Familiar process for most users
  • Import process requires user input, which can lead to inconsistent data, reporting, etc.
  • Data for learners who have not yet connected will be included in all reporting, leading to report management workload
  • Account Owners will have more User Management workload
  • Learners will need a unique Mursion Password, leading to password reset churn
  • Resetting passwords can cause missed sessions


Using a username or email address with a user-generated password is the traditional way to connect to websites. In this process, the Account Owner creates user accounts by entering a list or uploading a spreadsheet of user emails into the Mursion Portal. A registration email is sent to those email addresses. The user then clicks through to create a password, enter personal details, and finishes the registration process.

We do not recommend the "every learner has a user name and password" method. We recommend using a Single Sign-On to connect to Mursion. Learn more about manually adding users here. 

Learners connect via Single Sign-On (SSO)



  • Account Owners do not need to manually import or manage users
  • Reduces reporting to only include users who are actively using Mursion
  • Allows Account Owners to manage passwords, data and other security details in one location
  • Account Owner will still need to assign users to Teams
  • Up-front work is technical, and testing can be time-consuming. This time investment will pay for itself very quickly. 


Single Sign-On is a way for a user to connect to Mursion with an existing account provided by another platform. This can be something like a Google Account or your organization's email account.

Single Sign-On greatly reduces administrative overhead and security risks associated with password use all while simplifying the user experience. We highly recommend using an SSO for all organizations.  Learn more about integrating an SSO provider here. 

Learners Connect via SSO with Team Assignment



  • No need to manually import or manage users
  • Users are assigned to the team based on rules set by the Account Owner and their IT department
  • Reduces reporting to only users who are actively using Mursion
  • Up-front work is technical, and testing can be time-consuming. This time investment will pay for itself very quickly. 
  • Reduces reporting to only users who are actively using Mursion – no reporting on who hasn’t logged in


The Account Owner can choose to automatically assign learners connecting to Mursion via SSO to a team of their choosing. This process has all the benefits of SSO, while also reducing team assignment administrative work. Learners connect and are automatically provisioned to their team, giving the learner access to all the sessions their team is assigned to. 

This process also allows users to opt-in to Mursion training. If you’re offering Mursion to a group of users, but are not making Mursion sessions Mandatory, this is a good option. Remember, learners must always be assigned to a team, even in this opt-in method. 

Generally speaking SSO with Team Assignment has our highest recommendation. There is some up-front administrative work, but it will quickly pay dividends as it saves time in a multitude of manual tasks throughout the organization’s time with Mursion. Learn more about using SSO with Team Mapping here. 

What is a Team

Team is Mursion’s collective noun for a group of individuals who will be assigned to the same Mursion scenarios. All learners must be assigned to a team in order to schedule or attend a scenario. 

Different organizations group their learners in different ways. 

  • Department - Teams are named after the department they work for in your organization. For example, HR, Logistics, Sales, etc. 
  • Cost Center - Teams are named after the cost center that the users are organizationally aligned with.
  • Business Unit - Teams are named after the business unit the learners are a part of, for example, region, product line, etc. Some large organizations are split into smaller units that operate as an independent business. For example, Alphabet owns Google and YouTube. Alphabet would be the organization and Google and Youtube could each be a Team of users.
  • Course/Cohort Roster - Some educational clients have learners grouped via course roster. And grouping by start date is a good way to go. For example January Team, February Team, and so on.
  • Region - Geographically similar users can be pooled into a region-based team. 
  • Hierarchical - groups of learners based on where their position lies within an organization. For example, Front-line managers, Executives, Senior Managers

Team Structure Examples

The following examples are meant to be illustrative of the various possibilities and not meant to be a rulebook for how to structure your organization. You'll need to determine what works best for you.

Client A


This client wanted the ability to report how many learners in a particular business unit (Unit #1) completed a Mursion Simulation. They are less focused on the other group, which is a catchall group for any users not in the #1 business unit. 

How do Client A learners connect to Mursion?

Client A connects their 100k users to Mursion via an SSO. When the user connects, they are automatically divided into the correct team via their affiliation with the #1 business unit. 

Team Structure Suggestion

Two teams are assigned to each project. One team is the general user group, and the other is Unit #1. Teams remain assigned to each project, which has a long timeline and the Account Owner adds new scenarios as they come along. 

Client B


This client is deployed and managed by their Learning and Development team but paid for by an individual business unit, which will be taking the Mursion simulations. Completion data, Communications, and all other Mursion-related activity needs to be delivered back to the Business Unit and not the Account Owner. 

How do Client B learners connect to Mursion?

Client B creates non-SSO accounts for each of their 3000 users. 

Team Structure Suggestion

Teams are assigned by business unit, all teams are assigned to a single project. Each team has a Team-Level Facilitator, which reduces the need for Account Owner involvement, and allows the business unit to self-manage their Mursion experience more effectively.

Client C


The client is attempting to control the completion of a scenario on the cohort level. Each cohort will begin Mursion sessions at overlapping intervals, each lasting six weeks. They need data collected on a quarterly basis at the project level, and not the team level. 

How do Client C learners connect to Mursion?

ADP creates non-SSO accounts for 1000 learners per year, adding new users throughout the course of the year, as new cohorts come online. 

Team Structure Suggestion

Each cohort is a team. Each team is comprised of 26 learners, who are part of a larger six-week leadership program. The learners are spread across various regions and business groups. Teams are added to projects on a rolling basis by the Account Owner, and removed every six weeks, following completion of the course. 

Client D


The client is assigning everyone in their organization to the same Mursion simulations. 

How do Client C learners connect to Mursion?

Users connect via SSO with Team Mapping. 

Team Structure Suggestion

Just make one big team. Every learner is assigned to a team called Client D. When they connect to Mursion for the first time, they immediately have access to every available session. Because the learners are all taking the same content, there's less of a need to organize on a smaller scale. 

Guiding Questions for Team Organization

There are many ways to organize your learners into teams. Give it some thought before you begin, it can save you time in the long run. 

  • How many people from my organization will be taking Mursion scenarios?
  • Of those people, how many are taking the same scenarios? 
  • Are people going to be assigned to some scenarios but not others? 
  • How can I group people who will have common Mursion experiences? By organization? Department? Location? Learning Cohort?
  • Are my learners accessing Mursion all at once, or am I staggering access over a period of time?
  • How do you want to view your data? Are you going to want to track via region, department, cohort? It can be one of these, or a combination. Teams are just a way to collect a group of similar users who will be assigned the same Mursion content. 
  • Could adding Facilitators help you scale your Mursion program? 
  • Could adding Facilitators help to reduce administrative tasks that the account owner would otherwise perform?

Leveraging the Facilitator Role

An Account Owner is an organization-level administrator. Facilitators are a team-level administrator. Account Owners can add Facilitator privileges to any of the users in their organization. 

Adding Facilitator users is a good way to help distribute the administrative workload among your userbase. As you increase the number of users and sessions, it will become increasingly useful to add Facilitators. 

Facilitators can perform most of the administrative tasks as an Account Owner, with a slightly limited scope. Some clients use Facilitators to divide account ownership, making each Facilitator the responsible party for a group of Teams, which can help streamline tasks like reporting and user management for the organization. Learn more about what Facilitators can do here. 

Facilitators can be created following the standard user creation process, just select Facilitator when assigning the user role and assign the facilitator to a team

Client-level vs Team-level Facilitators

Facilitators can be given client-level access or team-level access. Client-level facilitators have nearly all the same privileges as an Account Owner.


Use Case




Client-Level Facilitator

Helpful for large clients, who may use Facilitators as account owners for a large Team or Teams, essentially working as an Account Owner for their team, but cannot see utilization data

ADP’s teams are organized into small cohorts. Each cohort has a Facilitator that makes sure the correct learners are added to scenarios but does not require access to other user data. 

Allows large organizations to be broken into slightly smaller sections, keeping user data siloed appropriately

Account Owner is still needed to create Facilitators

Account owner is still needed to assign scenarios to Teams 

Team-Level Facilitator

Helpful for any organization who is managing teams in such a way that Facilitators should not have access to client-level user data

Google creates teams based on business unit.  The Facilitator for Team YouTube acts as an Account Owner for the YouTube organization

Reduces data visibility to only those who need it. This is the primary benefit, in almost all cases Client-Level facilitation is superior. 

Increases the workload of Account Owners if client-level data needs to be reviewed, exported, etc.


Need More Help?

Hopefully, this guide was a helpful overview of the Portal structure, and how to start thinking about organizing your learner's experience at Mursion. If you ever have any questions, reach out to your point of contact at mursion. 

In the meantime, we'll keep expanding this as the portal evolves, but always feel free to submit any questions or suggestions for updating the knowledge base by leaving a comment on the link below: