To fix this issue:
The easiest way to fix this would be to change the Field Security permissions for the User, Team or Security profile on the field that is being restricted. This might not be that simple on a CRM system that is heavily customised.
So, you might have to first find the fields that have had Field level security applied based on the favourites that the user has added to their favourites list.
Find the user ID that is getting this error:
select * from Users
With this User ID: Find the favourites that have been added:
select * from UserRecords where usrc_UserId = <UserID>
In this table there are two fields that indicate which records have been added to the users favourites:
- usrc_EntityId
- usrc_RecordId
The usrc_EntityId field will indicate what entity type has been added. For example if the entity type is 10 then the record added was an Opportunty.
The entity type relate to the Custom_Table on the Bord_TableID Column:
select Bord_TableId, Bord_Caption from custom_Tables order by Bord_TableId
So, the corresponding relationship is
UserRecords.usrc_EntityId = Custom_Tables.BordId
To Find the Entity types of the users favourites we can run this SQL Command:
select Distinct Bord_TableId, Bord_Caption from Custom_tables inner Join UserRecords on Custom_Tables.Bord_tableId = UserRecords.usrc_EntityId where usrc_UserId = <UserId>
The usrc_RecordId indicates which instance of the entity is added. So if Entity is an opportunity (UserRecords.usrc_EntityId =10) then this will be an Opportunity Id (Opportunity.Oppo_OpportunityID).
With the above information we can narrow the search down to which entity types are being restricted.
We can then use this information to search the for the actual field level security permissions that have been added.
The field level securities are saved in the FieldSecurity table.
In this this table the column: FdSe_ColPPropsID will indicate the id of the field in the Custom_Edits table.
FieldSecurity. FdSe_ColPPropsID = Custom_Edits.Col_ColPropsID
In the Custom_Edits table there is also the column ColP_CustomTableIDFK which indicates the entity type from Custom_Table:
Custom_Edits. ColP_CustomTableIDFK = Custom_table.Bord_TableId
We can used this to find the field of the entity types that are possibly being restricted for a user:
select * from Custom_Edits where ColP_CustomTableIDFK in (select distinct usrc_EntityId from UserRecords where usrc_UserId = <UserID>)
We can then cross reference this with the FieldSecurity table to find the Field Level Securities that have been applied for these entities:
select * from FieldSecurity where FdSe_ColPropsID in (select ColP_ColPropsId from Custom_Edits where ColP_CustomTableIDFK in (select distinct usrc_EntityId from UserRecords where usrc_UserId = <UserID>))
The results returned can be used to find the permissions that could possibly be blocking the user from the field.
These permissions can be removed by deleting them directly from the FieldSecurity table or by setting the corresponding FdSe_Deleted field to 1.
We can also expand on the query above to narrow our search for the permissions that are blocking the users access:
select * from Custom_Edits where ColP_ColPropsId in (select FdSe_ColPropsId from FieldSecurity where FdSe_ColPropsID in (select ColP_ColPropsId from Custom_Edits where ColP_CustomTableIDFK in (select distinct usrc_EntityId from UserRecords where usrc_UserId = 2)))
We can then investigate each of these fields in the CRM Administration/Customisation/Entity and look through the field securities for each of these fields.