Security roles in MS CRM

Below are the some of the points about Security roles

1. Each privilege can have up to four access levels: Basic, Local, Deep, and Global.
2. If a record is created and the parent record has certain sharing properties, the new record inherits those properties. For example, Joe and Mike are working on a high priority lead. Joe creates a new lead and two activities, shares the lead with Mike, and selects cascade sharing. Mike makes a telephone call and sends an email regarding the new lead. Joe sees that Mike has contacted the company two times, so he does not make another call. Sharing is maintained on individual records. A record inherits the sharing properties from its parent and also maintains its own sharing properties. Therefore, a record can have two sets of sharing properties—one that it has on its own and one that it inherits from its parent. Removing the share of a parent record removes the sharing properties of objects (records) that it inherited from the parent. That is, all users who previously had visibility into this record no longer have visibility. Child objects still could be shared to some of these users if they were shared individually, not from the parent record.

3. Anyone with Assign privileges on a record can assign that record to another user. When a record is assigned, the new user or team becomes the owner of the record and its related records. The original user or team loses ownership of the record, but automatically shares it with the new owner.
4. In Microsoft Dynamics 365, the system administrator can decide for an organization whether records should be shared with previous owners or not after the assign operation. If Share with previous owner is selected, then the previous owner shares the record with all access rights after the assign operation. Otherwise, the previous owner does not share the record and may not have access to the record, depending on his or her privileges

5. Field Level Security:

                            There are a few additional rules that apply to certain attribute data types:

• Boolean attributes can be secured for create and update operations but not for read.
• Option set attributes can be secured for create, update, and read when a default value is unspecified

6. The System Administrator field security profile gives full access to all secured fields in Microsoft Dynamics 365. By default, all users who have the System Administrator security role have this profile. This profile is system managed and can’t be updated or deleted
7. When you call the Retrieve or RetrieveMultiple methods or messages, Microsoft Dynamics 365 evaluates if the caller and the impersonated user have access to each retrieved record (this is the regular security process) and each secured field. The call does not throw an exception if the criteria contain secured fields for which the caller does not have access. Instead, null values are returned for secured fields if they are part of the output column set.
8. If the caller (or impersonated user) does not have access to the secured fields that are included in the filter criteria, the field value is substituted with null during the evaluation of the filter.
9. When aggregating on secured attributes. Secured values are substituted with a null value, so normal SQL aggregation behavior applies
10. A programmer may build a client that uses Create and Update methods that interact with secured fields. When you call the Create or Update method, passing data for secured fields and the caller does not have sufficient permissions, an exception is thrown.
11. An administrator secures a number of fields for access in the application and wants the fields not to be available in reports. This allows for maintaining the same set of reports for all users. Filtered views will not return data for the secured fields if the calling user does not have authorization for the fields. When no field security is applied for any of the view’s attributes, the filtered views return complete data.