web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Blogs / Inside Microsoft Dynamics 365 / Security Structure in D365

Security Structure in D365

Views (1337)
dasdasd Profile Picture dasdasd 841
In D365 the security model is hierarchical, and each element in the hierarchy represents a different level of detail. Permissions represent access to individual securable objects, such as menu items and tables. Privileges are composed of permissions and represent access to tasks, such as canceling payments and processing deposits. Duties are composed of privileges and represent parts of a business process, such as maintaining bank transactions. Both duties and privileges can be assigned to roles to grant access to Microsoft Dynamics 365 for Finance and Operations.











Application Security Aligned with your Business
In earlier versions, administrators created their own user groups and manually assigned users to those groups. In Microsoft Dynamics 365 for Finance and Operations, security is role-based, and many security roles and duties are provided to help base security definitions. Using role-based security, users are assigned to roles, based on their responsibilities in the organization and their participation in business processes. Instead of identifying and granting access to application elements, the administrator assigns duties which users in the role perform. Because rules can be set up for automatic role assignment, the administrator does not have to be involved every time a user's responsibilities change. After security roles and rules are set up, role assignments are updated based on changes in business data.

Reusable Permissions
In Microsoft Dynamics 365 for Finance and Operations, a single set of roles applies across all companies and organizations. The administrator no longer has to create and maintain separate user groups for each company, as was the case in earlier versions. Even though roles themselves are not specific to a company or organization, the administrator can still specify a company or organization context for a particular user in a role.

MSDN Reference Link: Security architecture

This was originally posted here.

Comments

*This post is locked for comments