Update Permission Sets

When your environment is updated to a new version of 3PL Dynamics, the update often introduces new tables where information is stored. This page explains what an update permission set is, why it exists, and how you can use it to make sure your users keep working without permission errors after an update.

Why this matters

In Business Central, users are granted access through permission sets. A permission set describes exactly which tables and functions a user is allowed to read, create, change, or delete. Users only see and use the parts of the application their permission sets allow.

Most organisations do not simply hand everyone full access. Instead, access is carefully composed, often in customer-specific permission sets that were built to match your internal roles (for example a warehouse operator, an office employee, or a financial administrator).

Here is where updates come in. Every update can add new tables to the application to support new functionality or, in this case more important, replace existing functionality. Because those tables did not exist when your custom permission sets were created, they are not yet included in them. The result is that, right after an update, a user who tries to open an existing page or feature can run into a message such as "You do not have the following permissions..." even though nothing is wrong with the update itself. The access simply hasn't been extended to the new tables yet.

Manually finding every new table after each update and adding it to every custom permission set could be time-consuming and error-prone. Moreover, a 24-hour operation could come to standstill if any new tables are not immediately added to the permission sets of users. The update permission set solves exactly these problems.

What an update permission set is

An update permission set is a ready-made permission set that is automatically created and kept up to date during every update. It contains exactly the table permissions that were newly added since your previous version — nothing more, nothing less.

You will recognise it in your environment by its name:

New Tables - 3PL Dynamics

(There is one such permission set per Boltrics app, so the exact name reflects the app it belongs to.)

Think of it as a small, focused "top-up" of permissions. Rather than immediately having to rework all of your existing permission sets after the update, you assign this single set alongside them, and your users immediately gain access to everything the new version introduced.

How it works

You do not need to do anything to create or maintain this permission set — it is managed for you:

1. During the update, the system compares the version you are moving to against the version you were previously on.
2. It then determines which tables are new in this update (tables that already existed before the update are deliberately left out, because your existing permission sets already cover them).
3. It (re)builds the New Tables permission set so it contains precisely those new tables, granting full access (read, create, change, and delete) to them.
4. This repeats with every update, so the set always reflects only the most recent additions.

Note

Because the set is rebuilt on each update, it always describes the latest batch of new tables. It is not a running history of everything ever added — it is a snapshot of what changed in the update you just received.

How to use it

Using update permissions sets is a two step process:

1. Assign the "New Tables" permission set directly to the users, user groups or permission sets that should not be disrupted by changes in the update. This prevents permission errors right after an update.
2. Fold the new tables into your own permission sets after the update has been completed and before the next update. The permission set will reset on the next minor or major update; you must have merged the new tables into your custom permission set before that next update.

Frequently asked questions

Do I have to use it? No. It is offered as a convenience and is only important if you need to avoid disruption due to permission errors immediately after a minor or major update.

Does it give users extra access they shouldn't have? It only grants access to the tables that were newly introduced in the update. You remain fully in control of who you assign it to, so you decide which users receive access to the new functionality. You do not control what kind of table permissions might be part of the update permission set, but you can see what permissions will be assigned by inspecting the permision set in your TEST environment prior to the PROD update.

What if an update adds no new tables? Then the permission set simply stays empty, and there is nothing you need to do.