In this blog we show you how to create a build and a release pipeline in Azure DevOps that use one parameterized task group for deploying Azure Logic Apps and Functions to different environments.
Security configuration for any ERP implementation can be an intimidating task. To make it less daunting, you should know some key things. To begin, you will need to understand how security is structured in Dynamics 365 Finance & Operations, what you need from your clients, what you need to do as a consultant, how to configure security, and how to test the security setup.
Microsoft designed security in a role-based fashion. This means that you can assign roles to users, and you can have more than one role for each user. Each role in the system is made up of duties, which grants access to a certain part of the system. Duties are comprised of privileges, and these privileges grant you permission to perform an action in the system. Underneath permissions, you can modify access to be "Unset", "Grant", or "Deny" for "Display menu items" in the system. Display menu items are the most granular level that you can edit for security. One or more "Display menu items" are grouped to structure privileges.
The first step is to understand your client's needs and how they currently assign security to their users. There are many options your client has when configuring security in Dynamics 365 Finance and Operations:
To get a deep understanding of your client's needs, it will need to be documented. We recommend using an Excel sheet that lays out the users or roles – depending on how the client wants to configure security and some common functions within Dynamics 365. Have them fill the sheet out and specify what tasks each user/role should perform. This is a great starting point to configuring security.
As the consultant, you will need the completed documentation of you client's security needs. This means you will need to develop documentation to provide for them. This will be the Excel sheet referenced above. Once the documentation is completed by the client, you can begin configuring the security.
To configure security, you will want to start at the role level and work your way to a more granular level. Once the role is complete, you will assign it to the appropriate user(s).
Starting at the role level, you will make a copy of the out of the box role:
1. First, you will create a new role and add the name of the new role.
2. Next, you will select all the duties from your original role and copy them.
3. Paste the duties inside the new role.
4. If that is all you need to do for this client, assign this new role to the user. If you need to remove a duty from this role:
5. If you need to create a custom duty for this role:
6. Select the original duty, and copy the privileges that make up the duty.
7. Paste the selected privileges underneath your new duty.
8. After creating the custom duty, you will need to add this new duty to your new role.
9. Select the new duty that you want to put under the role and select okay.
10. Once this is complete and you are done creating your custom roles and duties, you need to publish your objects.
11. After you have published your objects, assign the role to the user.
12. Open the user up that you want to add the role to, and select assign.
13. Select your new role and click Okay.
Once security is almost configured, you will need to have a separate training session with the client's system admin to train them on how to configure security. The sooner they get involved, the better. You will need to train the admin on how you structured security, how to customize security, and how to test when issues arise. This will be longer and more in depth than most other end user trainings. Timing of this training is dependent on who is configuring security – the consulant or the client.
Once security is configured based off the currently defined specifications, you will need the client to begin their testing process. Best practices are to have security configured prior to the conference room pilot. Once the end users begin to use the system, they should be begin using their configured security roles. Make sure the security constultant or end user system admin is available to help troubleshoot. Testing early will give you a chance to understand what tasks they cannot perform, but need to be able to perform (positive testing). Once postive testing is complete, you can begin negative testing. Negative testing is for understanding what the end user can perform in the system that should not be accessible to them. This is a bit more challenging to test and can be done at a later stage when the end user is more comfortable in the system.
Some secuity best practices to keep in mind during configuration:
Hopefully, this blog makes Security configuration in your Dynamics 365 for Finance and Operations system a little less daunting. For more helpful Finance and Operation's tips check out our blogs! Looking to implement Dynamics 365 for Finance and Operations in your organization? We can help! Learn more.
Happy Dynamics 365'ing!