If the goal is to lock down a record once it reaches a certain state, you can use an Object Read-only Rule (also known as a Final State rule). I tested this and in an OOTB tenant, when an Incident is Closed all fields including the Attachment control are disabled:
To create an Object Read-only Rule:
- Log in to the tenant with the Administrator role
- Go to Configure Application
- Go to Business Objects
- Select the object you wish to modify, e.g. Incident
- Go to Business Rules
- Under Read-only Rules, click Add Object Read-only Rule
Note: If this button is not available, check the first Read-only Rule, it may be that you already have one.
- Add an expression which describes when the record should be read-only, e.g.
$(Status == "Closed")
- At the bottom under "Except Fields", optionally add any fields which you may still want to edit, e.g. ProblemLink_Category and ProblemLink_RecID so you can still link Problems to closed Incidents, and LastMod* in case contained records (like Task or Journal Notes) are updated
- Save changes
Now when you close an Incident, the user will not be able to add Attachments using the Attachment control.
Hope this helps!
which version of HEAT did you use for your test?
We are currently running HEAT 2016.2 and in our installation, users can still add and remove attachments to closed incidents (using the "Attachment" control") although we have a final state rule with the condition "$(Status == "Closed")" (i.e. exactly as you propose).
I tested on 2017.1, though I didn't find any bugs relating to flex control visibility rules which were fixed between 2016.2 and 2017.1.
The final state rule will only lock down the object if the role doesn't have permission to update in final state. Check the role permissions under Configure Application > Users and Permissions > Roles and Permissions > [role] > Object Permissions > [Incident] > Lifecycle column > Edit :
If that's not the cause, are you planning to upgrade any time soon? 2017.1 and 2017.2 are both bug fix releases, and 2017.2 will be out soon for Premise customers. If you don't have a good reason to stay on 2016.2, at least level up to 2017.1 and see if that changes anything. If not, we'll probably need to take a look at your configuration, so (assuming you have a support contract) you could open an Incident with us and we'll take a look.
Hope this helps!
The roles in question do not have the "Allow editing in Final State" permission set.
We plan to migrate to 2017.2 in the fourth quarter of this year. I will check then if it works as described by you.