An opportunity that I see for the SC platform is a more robust role feature.
There are groups, but currently feel that groups are a bit confused about their place in the platform at times and can lead to a large admin burden dependant on the organisation size.
What could roles offer:
- Define a role types that exist in your organisation
- Associate data access to each role
- Associate permissions for each role
- Associate what sites have each role
There would be the ability to then link users to roles at a relevant sites and potential flow on effects:
- Inspections completed could be owned by roles, scheduled inspections started would not be locked by a user as the role would own it
- 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.
- If the people in the role changes, all the templates, inspections, permissions, actions and schedules… you name it... would appear dynamically for who ever was in the relevant roles
- You could assign people to multiple roles and what was relevant would apply
Feel that this is similar to this post in some ways - Role based permissions
Anything further from others on this one?
Just to clarify when I obviously got distracted when writing… I mean
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!
Just to clarify when I obviously got distracted when writing… I mean
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.
It would be ideal if:
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:
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:
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:
Adding roles, departments, and custom profile fields would provide some flexibility and ease management. However, some precautions when building this feature out:
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.