Strange title…you probably wonder how this ties together. Well, let's start with a little [true] story.
Yesterday, one of my colleagues was unable to access any of her records in CRM, but was working fine the day before. It was an odd conundrum as nothing *should* have changed.
- The first step was look to ensure she had valid security roles. Yup…roles still there. [hint: this should have been enough for us to deduce the problem, but we tried a few more things before we figured it out.]
- We removed all of her roles and the re-added them, hoping maybe it would reset her account. No luck!
- She tried to access CRM on another machine, same results.
- We then removed her roles and sure enough, she got the expected can't access CRM at all.
That result finally tipped us to the problem…
She could get into CRM but not access any records meant it was a license problem. Sure enough, looking closer at her user record, her Access Mode was Administrative and she was set to restrictive access. We merely flipped back those fields to their appropriate values, and she was back in business.
Now, in hindsight, we should have checked the license first (or at least second), but it didn't jump out at us as nothing should have changed with it. So, if your user can get into CRM but not see any entity records, look at her license type immediately.
But, I was curious as to why/how it was changed. This lead me to check the audit logs and I discovered that the day before, another colleague changed her license type. After a quick chat, it turns out she was merely updating her employee referrer value, and must have accidentally changed those fields. Weird, but as shown in the screenshot below, it was pretty easy to see how that could have happened.
We have definitely seen that users can inadvertently change values as they tab or click through the form, and this exactly what happened here.
I have no idea how the Employee Referrer field ended up in the CAL section. Was probably an oversight during our upgrade. Note: we have already relocated that field.
The other item to address is why users are able to update Access Mode, Restricted Access Mode, and License Type. That should really more of a System Administrator task. Unfortunately those fields are not eligible for Field Level Security. So, we used our Dynamic Forms tool to secure those fields from all users except system administrators. Download our free community version of Dynamic Forms if you would like to do this yourself. If you don't use code/tool to protect these fields, consider moving those fields to a section away from the main parts of the form.
This situation provides a great reminder to consider your form layout and ensure fields are in the best possible location for discoverability and access, but also in cases like this we should have done a better job of preventing accidental changes to critical fields.