The ‘Loch Ness Monster’ is not that kind of ‘Lock’. Regardless, you want to lock monsters from ruining your system with bad data entry.

Lock Fields

In personalization, Lock allows users to view fields, but not change their values. To lock a field, right click, select personalize, and then check the lock button.

As with all personalization features, these locked fields can be distributed to other users as published saved views.

Can’t This Be Done Through Security?

Yes. Without personalization, controlling who can see or edit what fields is managed through security. If you click on security diagnostics for the Vendor form, you can see there are two security privileges: one to view vendors and one to maintain (edit) vendor data.

To lock down a subset of fields through security, a system administrator would need to create a new security privilege (or modified copy of the maintain vendors privilege) and assign it to the desired duties or roles.

An advantage of locking fields through personalization is that it is easier to see which fields are being locked through the UI. Also, users can have multiple views – It’s possible have a default view where the data is not editable, but allow the user to toggle to another view where the data can be edited. This would be a more difficult proposition to manage through security. Pro tip – if you care very much about tracking edits to a particular field, consider enabling database logging on that field.

Lock Many Fields

Personalizations can be applied to individual fields, as well as Field Groups or FastTabs. If you want to lock lots of fields on a form, the easiest way to do this is by opening the personalization toolbar, clicking Lock and then clicking on the desired Field Group or FastTab.

Clicking on the Payment group controls all fields in the Payment group

Clicking on the Payment FastTab controls all fields in the Payment FastTab

That’s pretty much the whole concept – Lock, Stock, and Barrel.

For want of a nail the shoe was lost;
For want of a shoe the horse was lost;
For want of a horse the battle was lost;
For the failure of battle the kingdom was lost—
All for the want of a horse-shoe nail.

Little things matter. Sometimes little things matter a great deal. Adding required fields helps prevent little bits of data from being lost on the great battlefield of D365.

Personalize Required Fields

In Platform Update 10.0.12. Require has been added as an option to the personalization toolbar.

As long-time readers will remember, the personalization toolbar can be accessed through the option tab, or by pressing the Ctrl+Shift+P hotkey. Once open, the user clicks on Require, then clicks on the fields to be required, and then closes the personalization toolbar.

Saved Views

As Saved views, these personalizations can be published to the desired members of the organization through security roles (see Publish saved views link below in additional reading for more details).

In addition to being a no-development solution, an advantage to this approach is that different fields can be required from different users. Imagine a business process where a general projects team create new projects across the company, but project managers are expected to enter a projected start and end date for visibility once they are specifically assigned to and begin maintaining their project.

Requiring the field through a saved view makes it easy for the project team to create and update other elements of the project through a standard view, while the Project manager’s view requires these data points to be entered.

Project manager view requires project start / end dates

Error message for Project manager not entering required fields

With fields populated, happy projects are all the same.