Ability to define roles

• Actions and schedules could be assigned to roles, instead of hoping to pick the 

Just to clarify when I obviously got distracted when writing…😎 I mean

• Actions and schedules could be assigned to roles, instead of hoping to pick the right individual or group from a long list - you could just select “Manager (of this site)” and anyone is that relevant role would get the assignment.

Really like how you’ve articulated this, and it’s definitely not an isolated request!

How many “roles” would you anticipate requiring within your team - and would these relate to a team member’s role within the organisation, or their role within the SafetyCulture platform?

I’m also curious, based on that - do you think an existing hierarchy (i.e. within your HR system) would be a good place to potentially map these roles from, and even automate any role movements? 

Keen to hear you thoughts!

I’ve updated your post with the missing bits @Ben Snyders 👍🏼

Related to this, I have a major issue with ownership where “roles” could help.  

• Someone leaves the company
  • I would delete the user, at which time it asks who you want to assign ownership to.  Most of the time, the replacement person is not yet hired, so I have to assign ownership of their templates to a temporary person. 
  • Half the time this works, half the time it doesn’t.  I’ve had major access issues with deleted accounts randomly remaining as owner or template and/or inspection access rules.  After a few months of support, I’m still ironing this out as it was a SC engineering issue behind the scenes. 
  • Once the new person is hired, the only way to change the owner to that new person is to ask the “temporary” person to go through each template one by one, not confusing any they owned previously, and change the owner to the new person.  This is a tedious process.
• A user is downgraded from paid to free
  • Ideally, I want to downgrade the person right away.  Instead, I have to ask them to filter to all templates they own, then one by one update the template owner to the replacement person.  This is a tedious process and relies on someone else to do this.  Supporting them, I now have to follow up on every template to make sure they did…

It would be ideal if:

• Ownership and/or access could optionally be assigned to a site-specific role (i.e. Metropolis Site’s Quality Manager)
• Ownership could be changeable by Admins with Data Access permission, not just the current template owner
• Ownership could be assigned in bulk by selecting multiple templates at once and a new button added to the bar that appears at the bottom to assign ownership to someone
• When downgrading paid users to free, it would behave just like deleting the user and ask who you want to assign template ownership to (since free users cannot edit templates, it does not make sense that they still own it but can’t change it)

Hey @Ben Snyders and @Corey,

Thanks for submitting this idea! We really like the concept of ‘Roles’ within the platform. The challenge we sometimes face with major changes like this is where to start? There’s so much opportunity and quite a bit of complexity with existing structures (Groups & Sites).

Our current thinking for an upcoming feature is to not only have ‘Roles’ within a user’s profile but expand that to a number of different ‘attributes’. This is a relevantly common experience with ADs and HR platforms. So instead of just name, we could have:

• Job Title (Role)
• Department 
• Contract type (Full time, Part Time, Contractor)
• Licences and Credentials 
• Custom fields so administrators can create their own fields. So for manufacturing that could be ‘Manufacturing Line’ etc 

Once admins can now flexibility ‘classify’ their workforce, we will then provide an automated way to automate group membership. Ie: (All current and future users who are a ‘Contractor’ and have the role of ‘Office Clerk’ will now be assigned to this Group). We believe this will help quite a bit with access and intersection with Sites.  

Ben, I know we have spoken about this a bit. But keen to hear anymore thoughts you might have, and also you Corey!

Below are some flaws with static groups and access today:

• We don’t want to give access to everyone in the company to create/edit groups for fear of making unnecessary groups, abandoning groups, improperly assigning group members, etc.
• The people assigning things to groups (which includes hourly employees) do not have a way to see who is in them, and often the group name is not enough to know the membership
• As people change job roles or sites we have to manually move them in and out of groups
• Static groups don’t always serve our needs or require extra management
  • Projects and new needs require adding and modifying groups
  • Report access for past inspections can require complicated thought process when making access changes
  • Ownership of templates can only be changed by the owner and is difficult to assign en masse to someone else
  • Schedules are “owned” by a person and can’t be changed, even if that user is removed

Static groups are still necessary, especially in cases where the group members cross boundaries. For example, you might have a group for “maintenance notifications” at a site that includes Plant Manager, Maintenance Manager, specific Maintenance Techs, and an Operator. You might have a group for “companywide safety coordinators” which spans multiple job roles/departments depending on the site.  You might be working on an initiative or project with cross-functional members that is temporary.  In some of these cases, “custom” user profile fields might be able to accommodate them, but not always. However, you’ll also still need groups that include all your managers at each site, all production inspectors, all warehouse personnel, etc.; these could be served by roles, departments, and custom fields.

Initially I was thinking access/assignments would allow for selecting a role or department so you don’t have to think about the people you need to add, but that may get complicated.  If we could add Roles, Departments, and custom fields, perhaps a feature could be added to Groups similar to EdApp to allow for “dynamic” groups.  As an admin, setting these up initially would take some time; long term, it would save time if the membership is auto-updated as you update someone’s profile (role, department, custom field, site). By default, just like in Schedules, the dynamic group’s title could be built for you (but changeable).  Some example dynamic groups:

• “Quality Leaders of All Sites” = Role - Quality Manager, Food Safety Manager
• “Chicago Site Managers” =  Role - Plant Manager, Production Manager, Office Manager AND Site = Chicago
• “Chicago Production Team” = Role - Operator, Associate AND Department = Production AND Site = Chicago

Adding roles, departments, and custom profile fields would provide some flexibility and ease management. However, some precautions when building this feature out:

• If these are used for permissions and access, they should only be changeable by users with the “User Management” permission (ideally in profile, when creating users, and in a matrix format). To everyone else, these should only be visible in their profile so they can’t give themselves things they should not have.
• Not everything works in hard “buckets” defined by a site, department, or role. There are situations when we have people wearing multiple job role hats outside of their main job title (such as a production manager also acting as the quality manager); add-on positions like “Safety Coordinator” that are added responsibilities; and scenarios where access/assignments/notifications cross boundaries on case-by-case basis.

Hi everyone,

Just a quick update on this thread and line of thinking. There are no plans to make a role that is not directly tied to a person. While I can see the use case for using a role as a proxy for an eventual hire when (re)assigning documents, the re-architecture of the way SafetyCulture word would be substantial.

We are making permissions simpler! I think assigning permissions has been very confusing and painful for a long time in the app, and we are now bundling permissions together into “permission sets” (which many have likened to roles). These will be only applied to users (not orgs, seat types, or groups) and make it very clear who can see what. They will be able to be customised, set when you add users, have bulk user functionality for changes, and defaults made for seat types. There should be no impact on anyone’s current permissions, it will just be easier to manage and a lot more transparent.

While I don’t have a date yet, we are also going to be finally adding in custom fields for users. This will allow for things like job titles, departments, etc. The next step from that is linking with user provisioning services (e.g. SSO providers) so these details can be automated. In parallel, we plan to also introduce Dynamic Groups which are populated by some rules/logic for users. That will also support these custom fields.

Permission changes are coming in July/August, and we’re hoping to bring out custom fields and dynamic groups will be later this year.