Hi All,
I am looking to setup permissions with groups. I am trying to not recreate the wheel. Does anyone have a template they have used for creating security groups and permissions for Kinetic? Thanks, Jen
I came into a system that has groups theoretically defined by role. In my opinion, this approach hasn’t been very effective in our organization. On a fairly regular basis, I get asked for an employee to be given access to a specific app, without giving access to all the other apps that go with that role. This has lead to a somewhat mishmash of individual users being granted access to some apps but denied access to others.
It’s on my to-do list to try to come up with group definitions and menu security that work well…but it hasn’t made it to the top of my list.
When I take the time to tackle this, I’m thinking about creating more granular groups and then assigning more groups to the users.
I’m curious to see what others respond.
Our users are assigned to user role groups in Active Directory. Some of those role groups are children of larger groups.
I have created a function that synchronizes groups and transitive user group memberships from AD to Kinetic.
When a new user is hired, they are put into the proper user role group and they get all of the required permissions. If a user’s role changes, that also automatically is updated in Kinetic
This has worked for us for the most part and requires very little management
1 Like
I love the idea, Michael!
The challenge with AD Groups, especially in web apps, is that there is no IsMember feature in the web. You get a limited amount of groups returned and then you have to keep retrieving them until you find the one you want or there are no more. Entra ID gets around this by using Application User Roles. (I think this is the video that explains it:
Working with the new App and User Roles feature in the Azure AD Portal (youtube.com)
The thing people don’t like about App and User Roles is there is no nesting. But then again, nesting groups often leads to over provisioning. 
I’ve always wanted one more level of grouping. I’d like a capability (CanDoSomething, etc.) and then those capabilities would be grouped into a role. It pretty much what @danvoss is promoting above - have more granular control with more “groups.” A nice ease-of-use thing is to add to User Account Security Maintenance would be to provide a way to copy those capabilities to the user by a role instead of adding them one by one.
To level up, add a time frame to the assignment so someone gets a capability for a certain amount of time and then it’s removed. Sprinkle some zero trust on it…
Lol, I just wrote some functions like that. Not quite related to this, but very similarly named.
The tricky part is some security is done with Security IDs and others with Groups. Menu and BAQ security use a Security ID with groups (and users 
) optionally associated with them. Service and Field security use groups directly. It’s a system that’s grown over time and there’s an Idea to improve on it at the Ideas portal.
1 Like
Currently this approach works really well in the Classic form.
The Kinetic form is way too difficult to use as you need to have to separate processes open at the same time.
I have setup security at a high level that has worked well.
Three types of users - (A )SuperUser, (B) Manager, and (C) User
Create security groups of
- Order-A !ORder SuperUser
- Order-B !Order Manager
- Order-C !Order User
- Prod-A !Prod SuperUser
- Prod-B !Prod Manager
- Prod-C !Prod User
etc…
Note the ! will put the Security Groups into the top of the Security screen for selection
For each functional area - using the allowed side of the security ID
In the setup area allow - A and B
In the General and Reports allow - A, B, and C
At the processing levels - assign
- A to setup tables - Territories, terms, etc.
- B to Customers, Parts, Suppliers - these are active
- C really shouldn’t need to be assigned at all as they will have access to all processes that aren’t limited.
At the User Level - assign to
- Superusers - Security Groups A, B, and C
- Manager - B and C
- User C
In addition to using security groups - some processes should be changed to read only or taken off the menu.
UOM and UOMClass are processes that should be read only because of the impact of any additions or changes made. A group consensus after testing should be used prior to changes or additions.
Transfer order shipment Entry - if you aren’t multi-site - you don’t need it.
1 Like
Thanks Bruce! They are setup in Kinetic but we may be able to leverage this setup to start.
I appreciate the feedback.
Have a great day!
Jen
