In Business Central, permissions define the actions that users can perform. A permission set is a group of permissions, grouped together. These can be assigned to an individual user or group of users. For more information, please read our guide on permissions in Business Central. In today’s post, we cover Microsoft’s changes to the ways in which users copy permission sets, specifically focusing on the three available copy operations. These changes were introduced in wave 2 of 2022. We also cover how to exclude copied permissions and notify users when a standard permission set’s been amended.
Three types of copy operation
On the Permission Sets page, when you click ‘Copy Permission Set’, a subpage opens. The key difference to this subpage, compared to how it looked previously, is the ‘Copy operation’ field. A copy operation is essentially a method of copying a permission set. As you can see below, there are three options:
Let’s run through these options and see what each does. To start, I have a permission set called TEST. I have subsequently created three copies of it, using each operation. To begin with, this is what my TEST permission set looks like:
As you can see, there’s three individual lines of permissions but also an attached permission set at the bottom. The attached set is the CONTOSO COFFEE ADMIN. The CONTOSO COFFEE ADMIN set consists of 62 rows of permissions. To easily find out how many rows there are, simply click the three dots next to a line, click ‘Select More’ and Ctrl C to copy all of the rows, which will tell you how many there are:
You could also export the lines to Excel and count them there.
The reason I am showing this is because the copy operations work in different ways. Using one over another will result in data appearing differently. Because of this, being aware of the TEST permission set’s contents beforehand is important. I need to use a permission set that contains both individual permissions and at least one other permission set to show these differences. Permission set-ception…
Copy by reference
When you copy a permission set using ‘copy by reference’, it will not populate the Permissions section with those that you’ve copied. Instead, the new permission set you create will include all permissions, individual or those part of another permission set (CONTOSO COFFEE ADMIN in my case), within a singular permission set. The set uses the name of the copied permission set which is TEST for me. As you can see below, the permissions aren’t listed. However, the copied permission set is:
Flat permission copy
The ‘flat permission copy’ takes all the permissions that make up the permission set you are copying from and lists them granularly. By drilling into the new permission set, you can see the permissions that make up the new set, without the system adding additional permission sets:
Clone
The ‘clone’ action takes a permission set and replicates the exact format in the new permission set. So if a permission set consists of three individual permissions and a permission set, like my example, the new permission set would too.
One drawback of both ‘clone’ and ‘copy by reference’ is that where you have a permission set within a permission set, you may unintentionally grant powers to perform specific actions. These might include actions you, as the administrator don’t want the user to have. Let’s next cover how to manage this.
Excluding permissions from copied permission sets
To exclude particular permissions, you don’t have to navigate through the copied permission set to modify individual permissions. Instead, you can specify individual permissions you don’t want users to have. To do so, add a permission to the new record and set the Type value to Exclude. This will override the permission held within the included permission set. Let me show you what I mean. Below, the image is the starting permission set:
As you can see, I’ve only added one permission but given ‘Read’, ‘Insert’, ‘Modify’ and ‘Delete’ ability. I next copied it using ‘copy by reference’.
On the newly created permission set, there’s an attached permission set as you’d expect. However, I can override the permission granted. To do so, I amend the Type to ‘Exclude’. After specifying which permission I don’t want the permission set to include, I change the ‘Insert’, ‘Modify’ and ‘Delete’ permission values. I have left the ‘Read’ permission as it was. See below:
When you click ‘view all permissions’, you can the see effect of the changes, with those manual amendments taking precedence over the attached permission set:
However, if you exclude anything, the permissions will still apply if they are included on separate permission sets assigned to the user(s):
Excluding permission sets within a permission set
In a very similar fashion to before, if you use ‘copy by reference’ or ‘clone’ and as a result have permission sets within the new permission set, you can change the Type value to Exclude. This, like with individual permissions, allows you to exclude a particular permission set within another set. Take the CLONE permission set for example. As you can see, I have set the CONTOSO COFFEE ADMIN permission set to have a Type value of Exclude:
This means the permissions it contains won’t carry across to the CLONE set. Users would only receive excluded permissions if they were included in a separate permission set. In this case, those permissions would have to be included in a permission set other than CLONE.
What are the implications in choosing a specific copy operation?
So, a ‘copy by reference’ simply takes everything that makes up the permission set you’re copying and puts it into a singular permission set in the new record. A ‘flat permission copy’ does the opposite, copying all the individual permissions, extracting everything in attached permission sets, formatting the new permission set simply as a list of permissions. Thirdly, the ‘clone’ method replicates the structure of the previous permission set exactly. If the permission set contains singular permissions, as well as additional permission sets, the new permission set will be structured in identical fashion.
Which operation is best?
I’d argue the ‘copy by reference’ operation is the best option as it copies across the entire permission set, not just the permissions. The reason I say this is best is because of future-proofing. If Microsoft add pages or actions to the system, they will most likely add permissions to existing permission sets to accommodate for them. If you have flat permissions and Microsoft updates the system, you may find yourself unable to complete typical system tasks; this could even include logging in! With that said, obviously Microsoft would only add permissions to standard permission sets, not those created manually by users.
On the contrary, for those who wish to be more cautious in how they apply new permissions to users, this may not be favourable. Whilst it’ll require more administration, some administrators may prefer occasional manual intervention over allowing users to have additional, undelegated powers. In those situations, ‘copy by reference’ isn’t the optimal choice. The other two operations would be more appropriate.
I would advocate using the ‘flat permission copy’ operation when you don’t want Business Central updates to affect the permissions users have. Microsoft won’t add new specific permissions to users, only to standard permission sets. So when you want total control, this is best. With a list of permissions, you have clear visibility of what is and isn’t included. You can sift through them, deleting any out that shouldn’t apply to this new permission set. This won’t affect the permissions in the original permission set. You can see every single permission clearly, without having to navigate to other attached permission sets unlike the other two operations.
The ‘Notify on Changed Permission Set’ action
Before I begin speaking about this field, I would like to reference That NAV Guy and his post on this particular field which goes into great detail. I would highly recommend giving the linked post a read if you’d like to explore this area in detail. It helped me understand this area of functionality.
By enabling the Notify on Changed Permission Set toggle, you are asking the system to provide a message when you open the Permission Sets page if there’s been changes to original system permission sets. Whilst the system notifies us that there’s been a change, it doesn’t tell us which permissions in the original permission set were added or removed. It does specify which sets changed though. This means users themselves should check for differences between the sets. Hopefully Microsoft enhance this in future, clarifying what changes have occurred!
Only system administrators (specifically, users with a SUPER or SECURITY permission set) will receive these notifications. The notifications in question won’t be emails, simply messages in the Business Central client, similar to those you might see on a sales order when there’s not enough stock to sell an item.
Enabling the Notify on Changed Permission Set action
You can only enable this toggle on Microsoft’s standard permission sets. For example, I can’t enable this on a permission set I created by copying another set. The toggle will be greyed out.
The below tooltip on the field itself is telling users to enable the specification notification on the My Notifications page:
On the My Notifications page, make sure to enable the ‘Original System permission set changed’ notification:
Closing remarks
Thanks for taking the time to read this. I know permissions are complex enough on their own, so when you add in different ways to copy sets it can seem confusing. Hopefully this post clarifies some of those queries! If you have any comments or questions, please don’t hesitate to contact us. We appreciate your feedback! To never miss our posts, make sure to follow us on LinkedIn.