Make a field ReadOnly with Business Rule.

[prabh]

Hi All,

How can I Make a field ReadOnly with Business Rule.

Thanks !!

Regards,

Preety.

[Robert Chrystie]

Hi Preety,

You wouldn't typically use a business rule to enforce read-only on a field.   There are multiple ways that you can do this, depending on your requirements; some examples are ACL's, UI Policies, Client Scripts, or even in the dictionary entry.

If memory serves me right ACL's are evaluated first, then UI Policies, then Client Scripts; I am not sure where the dictionary entry evaluation would fall in this lineup.   Keep this in mind when selecting your method as it can affect performance.

Thanks,

-Robert

[prabh]

Hi Robert,

Thanks for your reply !!

As per my requirement, whenever the incident is resolved then worknotes should be editable only for admin user , for rest it should be read only.

I have created UI Policy, its working fine but I want these changes to apply after insert operation in DB.I mean when I click the resolve incident button then after clicking the button changes should apply on Workinfo field.Thats why I was thinking to make a after BR.

I dont know much about ACLs.Please advice if this requirement could be done with ACLs

Thanks & Regards,

Preety.

[camds · Accepted solution]

Hi Preety,

This is definitely the place to use an ACL. There is a good outline of ACLs on the wiki here Using Access Control Rules - ServiceNow Wiki

To add an ACL for what you describe you would create a write rule for the Incident.Work_notes field for the when the status is not closed and status is not resolved. Then add the ITIL role to the ACL.

This will allow access to the field when the conditions are true and block access when they are false. If you select the "Admin overrides" check box then Admins will be able to write to the field even if the conditions are false.

Cheers,

Cameron

[Robert Chrystie]

Hi Preety,

Like Cameron mentioned this can be done with an ACL.   Two things that I would add is that you should really review your other ACL's to understand what all is happening on the table you are working with, and that adding an ACL to an extended table doesn't apply that access to the base table.

What I mean by these things is that OOB there are other ACL's in place to prevent ITIL users from writing to a closed incident.   So, while you can add that condition into your new ACL, keep in mind that there might be other ACL's that are also affecting the table in ways that might not be abundantly obvious.   Additionally, the Incident table extends the Task table.   OOB there is a write ACL on Task.work_notes that you will need to review in addition to creating a new ACL for Incident.work_notes.

For a better understanding of ACL's the link that Cameron provided is a great resource.   I would also add that Chuck Tomasi and Andrew Kinkaid recently hosted an Ask the Expert session on debugging ACL's in Eureka.   This video shows not only how the new ACL debugger works, but also provides insight into the order in which ACL attributes are evaluated, and other tips/tricks.  

Ask the Expert: TechNow - Eureka Access Control List (ACL) Debugging

I hope this helps!

Thanks,

-Robert