Skip to main content

The last thing we need to do is to set up the user permissions.

Regulations, policies and laws – certain rules and rights are not only key aspects of day-to-day life but also when it comes to dealing with ERP systems.

Just like in day-to-day life, it is also necessary to clarify who is allowed to, and who is definitely not allowed to, do what in an ERP system. At first sight, answering this question might appear to be an easy task.

But how does it work in practice?

Once you understand that the user permissions need to be set up in an ERP, the first step is to define who the individuals with lop-level responsibility will be. Personnel in the IT department are usually the fortunate ones assigned this responsibility. And even when the initial euphoria about this has passed, the impression tends to remain that assigning user permissions can’t be very challenging.

But, unfortunately, the IT department has only been marginally involved in the ERP implementation project up to this point in time. The relevant processes and functions in Dynamics 365 are generally not understood in detail by those who have just become responsible for the assignment of user permissions. The first task for IT to tackle is to get their hands on the necessary knowledge, by means of training, white papers, etc. The basic process-related knowledge required can be acquired by consulting with those responsible for the processes.

Once the initial challenges have been mastered, those responsible for IT can start assigning the user permissions. The first logical step here is to allocate the standard security roles of Microsoft Dynamics 365 for Finance & Operations (Enterprise Edition) to the users.

Obstacles on the way

The following problems arise here from a technical point of view:

  • The standard roles often don’t match the roles that a company actually needs.
  • As a result, users are frequently assigned multiple standard roles as a means of giving them all the rights they need.
  • Due to the fact that the standard roles are often very comprehensive, users often have more permissions assigned to them than they actually need for their day-to-day work.
  • Another problem besides the comprehensive scope of a standard role is the fact that this role automatically displays numerous buttons, functions and screens which are not necessary. Maintaining a clear overview is one of the objectives associated with the assignment of user permissions.
  • If a user has been assigned multiple roles, then maintaining a clear overview becomes even more of a challenge.
  • User permissions in connection with individual fields are hardly taken into account in the standard roles.
  • And without programming, setting permissions at row level is only possible in some areas.

There are also tricky administrative challenges to be overcome:

  • The tools available at this level of detail provide only non-descriptive terms or misleading information with regard to the elements for which permissions can be assigned.
  • In-house developments are often not correctly integrated into the existing tasks and roles, which is why user permissions have to be manually assigned after the fact.

In terms of the ERP implementation, even further challenges arise in connection with the usual project workflow:

  • The issue of user permissions is often one which crops up relatively late during the project implementation phase. This is because the detailed clarification of the processes takes place before user permissions are assigned. It is for exactly this reason that there is often considerable time pressure when it comes to assigning user permissions. Why? Because either major milestones are fast approaching, such as integration testing, or because the go-live has already taken place.
  • As the department responsible for the user permissions, IT often doesn’t have time to test the assigned permissions in practice. There is also a lack of the in-depth process-related knowledge needed as well as a detailed understanding of the responsibilities and the interfaces between the various departments.
  • It is also not really possible to assign the setup of the permissions to a third party; this is a task which the company needs to deal with itself. The reasons for this are the associated responsibility, the resulting work and also the future support and modification work which will be necessary over the entire lifetime of the ERP system.

The assignment of user permissions is an issue which tends to be unpopular during implementation projects due to the fact that it is time-consuming, requires considerable testing and appears unproductive. Tasks often become more complicated as a result of assigned user permissions or existing processes and functions no longer work as well as they initially did.

Finally there?

Despite all of these complications, the IT department is finally satisfied that the user permissions have been set up.

“Our roles are finally set up the way we want them.”

Much later, however, when checking which licenses or subscriptions are needed, IT gets the shock of its life: all of the roles assigned require Enterprise user licenses or Unified Operations Plan / Dynamics 365 Plan subscriptions – the most expensive option per user.

This means for IT:

“After all that effort, it’s back to Square One.”

How can this situation be avoided, and what is the best way of dealing with the issue of user permissions?

Ideally, the standard roles will already be in use at the outset of the project so that all of the training, testing and process-related activities can be performed with the assigned user permissions. It is also important to always bear the issue of licenses / subscriptions in mind. This approach might be the ideal one from the point of view of user permissions, but it also adds another layer of complexity to a project which is already comprehensive.

The recommended approach for the assignment of user permissions is therefore the following:

  • A concept for the administration of user permissions plays a key role during the implementation phase. That is why it is already important at the early stage of a project to consider which employees need which security roles and which roles require which permissions.
  • It is also necessary to define a certain role hierarchy as part of this concept. This allows roles to be defined for various permission levels (e.g. management and multidisciplinary functions, etc.).
  • It also needs to be decided for each role whether the standard role(s) need(s) to be used and appropriately modified or whether it is necessary to create a new role.
  • It is necessary to consider which permissions are needed as early as when specifying the need for system modifications.
  • The process of assigning user permissions should be regarded as an integrative process involving both those responsible for user permissions and the key users. The first step is taken by IT and involves preparing a proposal showing how the various roles could be defined. This draft then needs to be revised with the input of the key users. Only after this has been done should the system-based permissions be assigned and then tested by the key users. The proposed modifications based on this testing are then coordinated with IT and the roles are modified accordingly. Once the permissions have been fine-tuned, the security roles are again tested by the key users in the relevant departments. This procedure should be repeated for as long as it takes until the roles created correspond with the needs and requirements of those involved.

And, because even all of the tips and tricks listed above can’t resolve all challenges and problems, we still have:

One ace up our sleeve

The Security & License Cockpit we have developed in-house not only helps assign and maintain user permissions. This tool is also designed to help you keep an overview of assigned permissions and license or subscription costs incurred.

The Add-On is available for all versions of Microsoft AX 2012 as well as for Microsoft Dynamics 365 for Finance and Operations (Enterprise Edition) starting with Platform Update 3 (November 2016 release).

Interested in our solution?