Business Central: Copying Permission Sets

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:

This image displays the Copy Permission Set subpage that opens after navigating from the Permission Sets page. More specifically, the image shows the three options that show after clicking the dropdown on the Copy operation field. These three options are:

Copy by reference
Flat permission copy

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:

This image shows the three lines of permissions on the TEST permission set I created. I will now copy this using the three different copy operations to see how each operates.

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:

This image shows the CONTOSO COFFEE ADMIN permission set. It contains 62 individual permissions. I will attach this permission set to the TEST permission set.

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:

This image shows the permission set created from the TEST permission set, using the 'copy by reference' copy operation. No individual permissions are listed. Instead, it simply contains one permission set attached, which contains all of those from the TEST permission set.

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:

This image shows the FLAT PERMISSION COPY permission set. As you'd expect, this permission set was created by copying the TEST permission set with the 'copy operation' 'flat permission'. The image shows all the individual permissions that make up the TEST permission set, listed.


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.

This image shows a permission set created by using the 'clone' copy operation. This permission set looks identical to the original TEST permission set, being made up of three permission lines and the CONTOSO COFFEE ADMIN permission set.

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:

This image shows a permission set which I will copy. It includes one permission, with each value set to 'Yes'.

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:

This image shows a specific permission line excluded on a permission set, except for the 'Read' permission.

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:

This image shows the Expanded Permissions page. It shows for one line, only the Read Permission is set to Yes, whilst the Insert, Modify and Delete are blank.

However, if you exclude anything, the permissions will still apply if they are included on separate permission sets assigned to the user(s):

This image shows the Effective Permissions page. Specifically, it shows permissions are enabled, despite being set to Exclude. This is because they are included on a different permission set.

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:

This image shows the My Notifications page, highlighting the 'Original System permission set changed' notification which must be enabled to produce a 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.

Leave a Comment

Scroll to Top