Staff Roles

Owned by Seth Petry-Johnson
Last updated: Jan 02, 2024
7 min read

ee also: Organization Staff (for a high level view) and Staff Accounts for more information on individual Staff accounts

Overview

Staff Roles exist so that staff members of an organization (e.g. a Provider) can be granted the ability to work on data belonging to that organization, but without “logging in as” the Organization account directly.

Additionally, they allow for Staff users to be associated with multiple Organizations, having different levels of access for each.

A key thing to remember is that Staff Roles and Member Roles are not the same thing! They are similar, and both are configured via Admin → Roles, but they are fundamentally different things in LearningBuilder.

 

Member Roles

Staff Roles

 

Member Roles

Staff Roles

Purpose in LearningBuilder

Tracks a Person or Organization’s progress towards a credential, or grants access to functional areas of the site.

Links a specific Person to a specific Organization, specifying the permissions they have for that relationship.

Permissions

Apply equally across the entire site.

Take precedence over Staff permissions.

Permissions are only relevant in specific parts of the site where the staff can “act in a Staff capacity” on behalf of a parent Organization.

How are these Roles granted?

Managed by the Workflow Engine, so they are granted through a managed process that can collect custom data fields.

Assigned in a one-step process from the Admin area and cannot be associated with any custom fields.

Can be the assigned “Role” for a Workflow Step?

Yes

No - Staff Roles do not participate in the Workflow Engine. This is why the “Organization Staff” Member Role exists; see below.

Intro to the built-in “Organization Staff” and “Provider Admin” Roles

There are two built-in Roles that participate in the Staff system:

  • “Organization Staff” is a Member Role

  • “Provider Admin” is a Staff Role

The “Organization Staff” Role is automatically granted to all users that have at least one Staff Role. No other Role can serve this purpose.

The “Provider Admin” role has no special significance, other than it is the only built-in Staff role. You can create additional Staff roles if you need to. One reason to do this is to allow for different levels of access for different types of staff; for instance, the “Provider Admin” can be given full rights to an Organization, while a custom “Provider Employee” might be given restricted access.

The built-in “Organization Staff” Member Role, versus custom Staff Roles
Diagram showing difference between Org Staff, Provider Admin, and custom Staff Roles

Purpose of the “Organization Staff” Role

The “Organization Staff” Member Role exists because Staff Roles do not participate in the Workflow Engine, and therefore cannot (on their own) grant a staff person the ability to act on Workflow Steps available to their parent Organization.

For instance, consider a Provider account that wants to allow its employees to create and submit new educational courses in LearningBuilder.

Creating a new Activity requires launching Step 1 of the Create Activity Workflow, which means that the user must have a granted Member Role matching the Step’s “To Be Completed By” setting. By automatically assigning all Staff accounts the “Organization Staff” Member Role, it is possible to configure the Workflow in a way that allows them to access it.

In this screenshot all steps are performed by Organization Staff, but that’s not always the case.

It would be possible to configure Step 2 to be completed by “Provider”, which would allow the Staff members to submit the course data, but would require the Provider organization itself to make the payment.

“Organization Staff” is not a normal Member Role

The “Organization Staff” role is granted automatically when a Staff association is created. Unlike other Member Roles, it does not have a Grant Role Workflow and does not collect any Workflow Attributes.

Assigning permissions to the “Organization Staff” role

The Organization Staff role exists for only two purposes:

  1. To allow Staff users to work on Workflows belonging to their parent Organizations;

  2. To allow Staff users to access the My Account area, if they have no other Member Roles

Therefore, the Organization Staff Role should only have the following permissions:

  • ProviderArea_Access, so that they can access the Provider area;

  • MyAccount_Access, so that they can access the My Account area;

  • Any other relevant MyAccount area permissions that are deemed necessary

What can Staff accounts do on behalf of an Organization?

Staff accounts primarily exist so that individual employees of an organization can have their own individual logins, but still manage data belonging to the organization.

The main things that a Staff account can do on behalf of a parent Organization are:

  1. Manage Activities (e.g. manage educational courses provided by a Provider) including Reporting Attendance at those Activities

  2. View the Organization’s profile and supporting pages

  3. View the Organization’s communications

Creating a “Staff” type Role

Staff type Roles are created in Admin → Roles, and only support “Member” types of accounts; Organizations cannot be “staff” of other Organizations.

Creating the Role

Assigning Permissions to the Staff Role

Permissions are granted to Staff Roles just like they are granted to Member Roles.

The application of those permissions is a little different, however.

If a user ONLY has a permission via one of their Staff Roles, and not one of their Member Roles, then they can only perform that task for the specific Organization(s) the Staff role is related to.

FAQs

1

Why is the Organization listed as its own staff member?

Each Organization has a “self-referential” Staff association to itself so that a user can log in directly as the Organization and access the Provider area. This is necessary because accessing the Provider area is dependent on having Staff Role and Permissions.

2

Why don’t I see the “Organization Staff” Role listed on the Member Profile page?

Unlike normal Member Roles, Staff Roles are not managed by the Workflow Engine. The Member Profile page only lists Member Roles with Workflow attributes. Since there are no data elements to collect for a Staff role, and there’s no “process” of granting a Staff role, there’s no reason to display them on the Profile page.

3

Why can I search on “Organization Staff”, but not Staff roles?

You can filter the Admin → Members page by Role, but the list of options does not contain Staff roles.

This is because the Admin → Members page is searching for Member Role data, which is controlled by the Workflow Engine. Staff Roles aren’t Member Roles, and so they aren’t searchable here.

4

What Roles must be assigned for a standard Provider configuration?

A Provider Organization needs the following:

  • The built-in Provider Role, which grants access to the Provider area of the site;

  • A self-referencing Provider Admin Staff Role

  • The Organization Staff Role (which is auto-assigned with the Staff Role)

5

What does the Organization Staff role do? Why does it exist?

The Organization Staff role allows users who have Staff Roles to work on workflows, such as Activity Definition workflows. This is needed because Staff Roles are not Member Roles and workflows depend on a user having a Member Role to act on a workflow step.

In order to work around the fact that Staff Roles are not real Member Roles, LearningBuilder automatically assigns the Organization Staff role to users when they are assigned a Staff Role.

6

What permissions should the Organization Staff role have?

See Staff Roles | Assigning permissions to the “Organization Staff” role, above.

7

How can I tell if a person is a Staff of an organization?

See Staff Accounts