Automating User Group Assignments Based on Profile Rules

I believe something like this is in EdApp and is common in LMS.  When I add new users, which is manual, I have to know what work they will do in SafetyCulture, what site they are from, and their job title.  That dictates what user groups I place them in.  Sometimes I miss one.  If the person moves or gets a job title change, I have to update their groups. 

For me, the rules would primarily be based on Site and Job Title.  Department could be a way to streamline as well.  For accidents, we have dedicated people at each site (in various roles) that are designated to be the primary investigator for accidents.  Only a few other people can see the reports to protect HIPAA information.  So perhaps there are some cases for custom fields in a user profile. Additionally, for Issues notifications, we have people placed in groups for each category, but this is a bit more complicated because the pattern of who is in them for each site varies.

Groups I have are:

• Per site - all users
• Per site - management
• Per site - supervisors
• Per site - maintenance
• Per site - production 
• Per site - warehouse
• Companywide - managers of all sites
• Companywide - SafetyCulture administrators of all sites
• Companywide - safety coordinator of all sites
• Companywide - quality managers of all sites
• Per Issues category - users to be notified

Hi Corey and Gary.

Im Kael, a product designer here at SafetyCulture.

We are currently looking at this and exploring if allowing you to add people automatically to groups based on profile/user field combinations or introducing roles and teams/departments as structures similar to groups today, which you could then use for inspection/course access and assignment.

The benefit of the latter is that you dont have to create groups and match them with the fields for every group = role or location. 

I’d love to learn more and walk you through the thinking if you are interested?

For us, I think options for selecting the “role” (job title) or the department/team would cover most cases. 

Anywhere you can assign or give access in the platform could have options for:

• Users
• Groups
• Sites
• Job Role (i.e. all Quality Managers at all sites)
• Departments/Teams (i.e. all maintenance departments at all sites)
• Dynamic based on Site Selected
  • Full Site
  • Specific Department/Team at that Site
  • Specific Job Roles at that Site

If you gave all those options, then as you stated, that would keep us from having to manually create these groups or rules for dynamic groups.  You would need the flexibility to be able to select multiple job roles/departments in each of those rules though.

Then manually created groups could still be just that - for situations where it does not follow a pattern like that 100% of the time.  

My fear is this could look complicated though.  It might be more intuitive to move the current Sites/Dynamic rules options out of the dropdown and limit it back to Users and Groups.  Then just allow us to create rules for all those options of static and dynamic groups based on site, job role, and department as we want and naming them as we desire.  That leaves the work up to admins as to what options they want to provide and to be able to name them where their company understands it.  This simplifies the daily end user’s experience.

Out of curiosity, if you had roles, departments/teams and sites/locations, what would you use groups for?

I hear you regarding it being complicated. That’s something we are being mindful of, especially after receiving feedback that the existing site + group-based access rules can be difficult to setup.

If we did move sites out of the dropdown, would that mean you’d have to create a team for every site to achieve site + group/team access rules?

If we only had roles, departments/teams, and sites then it would not be enough. Those only accommodate rigid groups, but there are groups that need to be more flexible.

Using those 3 things, as I mentioned, we’d have a few combinations that would need to work with and without the site being part of it.  Specific site(s), specific role(s), specific department(s), specific role(s) within a site, specific department(s) within a site.  And of course the option to be dynamic based on the selected site.

However, there are many groups where it is not so straightforward.  Here are examples.

• Issues - Food Safety - Those who want to be notified of food safety issues; works dynamically based on selected site and includes various roles across multiple sites inconsistently.
• Issues - XYZ - and so on for all issues categories.
• Companywide Safety Leaders - specific person in each site who coordinates the safety committee which may be a person in a different role at each site
• Site Packout Team - users at a specific site that do inspections in a specific area of the plant
• Companywide Quality Leaders - all quality leaders from all sites; some are in a multi-hat role so they don’t have the same title as others, but we can’t include everyone with that title because at other sites that title is not the quality leader
• Corporate Building Coordinators - an assigned person for each building at headquarters who handles safety inspections/drills for that building

The only way for profile settings (site, department, role) to accommodate all of those various options would be to add something to their profile for each one.  It would be either a lot of custom fields to select as “yes/no” on each person or require a few “open” custom fields so we can put those in as needed (some cases a person may need multiple). Then we’d have to be able to select those custom fields to use them. 

There would have to be a lot of thought put around this for it to work.  That’s why I suggested you could potentially keep the feature as “groups” and allow us to build our own dynamic flows for the groups and name them what we want.  

Ok, that makes sense. Thank you for the detailed examples. This feedback helps a lot.

In regards to:

Issues - Food Safety - Those who want to be notified of food safety issues; works dynamically based on selected site and includes various roles across multiple sites inconsistently.

How do you determine who needs to be notified of food safety issues? 

For the groups that are associated to each Issues category, I add people from each site that say they want to be notified for that category.  That varies by site as to whom wants/needs to be notified and have access to them.   The same goes for other “custom” groups like the safety leaders, which will be one person per site, but various titles across all the sites.

I would have to standardize/force who gets Issues notifications which won’t satisfy everyone by a long shot. For the safety leaders, building coordinators, quality leaders, packout users, etc. I would need to have a custom field to add those extra “roles.”  Potentially someone could be in more than one of those at the same time.

Briefly read how you use and it is an excellent read.

Without sounding alarmist this needs to be as simple as possible and managed by admins etc who can the use the simple rules for roles and sites.

Job roles is a key thing in our industry as I am looking not just at variable methods to control but also by linking…

Inspections... 

-Assets...

-Training... 

-Heads up.

Etc to the Job roles and Sites…

This mix on the control side for the Org with the competency profile is what we are eager to build into the system when this has the hierarchy and filters.

Then we link the training with the gaps identified with inspection and action and the promote these from lagging indicators.

With regards to issues we have not rolled or embedded this at the moment based upon the construction industry that we are in having many transient worker versus employed personnel.

I also think that although not linked with a filter logical approach to control of teams, sites, roles etc that the labels (max 100) these are also an excellent area for data crunching gaps from the safety culture system.

As Corey has stated there will no matter what you do to improve this be personnel and premium users that will wear 2 or more hats based upon their roles and responsibilities.

Interesting subject.