I propose a feature enhancement for automating the assignment of users to groups based on specific profile rules within SafetyCulture. This feature aims to streamline user management, ensuring that users are automatically added to appropriate groups based on their job title, roles, and other relevant profile attributes.
Proposal Overview:
-
Extended User Profile Fields:
- Additional Fields: Enable more fields to be added to a user's profile, such as job title, department, and other relevant attributes, with the ability for Custom Fields.
- Dropdown Items: Allow for dropdown selections for various disciplines, such as First Aider, Fire Marshall, Fork Lift Truck Driver etc.
-
Automated Group Assignment:
- Develop a rule-based system to automatically assign users to specific groups based on their profile information.
- Rules could include combinations of job titles, roles, and custom attributes to ensure precise group membership.
Current System Example: To illustrate how this can be effectively implemented, I have attached a screenshot from our current Learner Management System, Absorb. This system allows us to scrape user profiles and automatically add them to specific groups based on defined criteria. This functionality has significantly improved our user management efficiency and could provide a valuable reference for the implementation within SafetyCulture.
Benefits:
- Efficiency: Automating the group assignment process reduces the administrative burden on managers and ensures that users are always in the correct groups.
- Accuracy: By using predefined rules, we can ensure that group memberships are consistently accurate, reducing the potential for human error.
- Scalability: This system can easily scale with the organization as new roles and groups are created.
Request for Development: I kindly request that this feature be considered for inclusion in an upcoming sprint. Implementing this functionality will greatly enhance the user management capabilities within SafetyCulture, providing significant value to administrators and end-users alike.
Attachments:
- Screenshot of Absorb LMS demonstrating the automated user group assignment based on profile scraping.
Thank you for considering this proposal. I am happy to discuss this further and provide any additional information or clarification needed.
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:
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:
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.
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:
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.