What are the high level steps to enable field level security?

• Enable field-level security for an attribute
• Create a field-level security profile
• Associate users or teams with the profile
• Add specific field permissions, such as Create, Update or Read for a specific attribute to the profile

Can we control the field level security based on security role?

No we can't. It can be managed only via Security Profile.

Field Level Security Interview Question in MSCRM

1. What is the importance of field level security in CRM?
2. What are the permission we can restrict on specific field with field level security?
3.What are the high level steps to enable field level security?
4. What will happen if a field is enabled for field level security?
5. What a field level security profile contains in CRM?
6. Can we add user/team to more than one field level security profile?
7. Can we delete System Administrator field level security profile?
8. Can we set field level security for OOB fields?
9. Do Audit history maintained for enabling and disabling field level security by setting “IsSecured” on a field?
10. What will happen if the user don’t have “Read” security on a field?
11. How can we know what are all attributes can be secured in CRM with field level security?
12. Do all attribute data types support to restrict all permissions with field level security?
13. Which security roles allow you to see secured fields?
14. What will happen if multiple profiles assigned to user/team?
15. How do secured fields behave for create or update?
16. How do secured fields behave for Retrieve and RetrieveMultiple?
17. How do secured fields behave when records are shared?
18. How do secured fields behave for filtered views?
20. How do secured fields behave for offline synchronization?
21. Can we control the field level security based on security role?

How do secured fields behave when records are shared?

A user with access to a secured field in a record can choose to share it with another user or team. The user gives only the access that they have on the record. For example, to share the record and for grant update privileges, the user must have update privileges. You can share a secure field on a particular record with read and/or update with a security principal (User or Team). The user or team member with whom the record was shared now have that type of secured field access only on the shared security fields on only that particular record, even if the user or team member to whom it was shared doesn’t have field security profile that give them access.

How do secured fields behave for filtered views?

Filtered view will not return the data for the secured fields if the calling user doesn’t have authorization for the fields. When no field security is applied for any of the view’s attributes, the filtered view return complete data.

How do secured fields behave for offline synchronization?

Only the secured field values that you have access to replicate into the offline database. If you don’t have access to the data, it is not saved offline.

Which security roles allow you to see secured fields?

System Administrator • The system Administrator field security profile gives full access to all secured fields in Microsoft Dynamics CRM. By default, all users who has System Administrator role have this profile. This profile is system managed and can’t be updated or deleted.

What will happen if multiple profiles assigned to user/team?

User/Team received the least restrictive permissions

How do secured fields behave for create or update?

It will show “Insufficient Permission” error on creating/updating the record.

How do secured fields behave for Retrieve and Retrieve Multiple?

When user call the retrieve/retrieve multiple messages, CRM evaluates if the user has access to each retrieved record and each secured field. CRM won’t show error message if the retrieve column set contains secured field instead null values are returned for secured fields.

Do all attribute data types support to restrict all permissions with field level security?

No, 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

Do Audit history maintained for enabling and disabling field level security by setting “Is Secured” on a field?

No

What will happen if the user doesn’t have “Read” security on a field?

The field in the form shown as NULL values

How can we know what are all attributes can be secured in CRM with field level security?

There are thousands of attributes from all entities those can secured with field level security. We can get those attributes in two ways: • Install metadata browser for the customized CRM and query the entity metadata for the following properties CanBeSecuredForCreate, CanBeSecuredForRead, CanBeSecuredForUpdate • Open EntityMetadata.xslx file for uncustomized CRM and query the entity metadata for the following properties CanBeSecuredForCreate, CanBeSecuredForRead, CanBeSecuredForUpdate

What a field level security profile contains in CRM?

Field level security profile contain all the fields from all the entities which are enabled for field level security.

Can we add user/team to more than one field level security profile?

Yes, we can

Can we delete System Administrator field level security profile?

No, we can’t

Can we set field level security for OOB fields?

No, we can’t

What are the permission we can restrict on specific field with field level security?

Below are the security permission that we can restrict the users/teams on individual fields:
o Read
o Create
o Update

What are the high-level steps to enable field level security?

Below steps are: • Enable field level security for an attribute • Create a field level security profile • Associate user and team with the profile • Add specific field permission like create, read, update for specific attribute to the profile