Contextual security manager Unlike the simple security manager, the contextual security manager is aware of the system's table hierarchy, which means you can potentially have different security rules for a field based on where in the hierarchy it is displayed. Note: Functionality described here requires the Admin role. Note: This section assumes you are familiar with the contextual security manager and its ACL base functionality. The basic rules to remember with the contextual security manager is that it looks up the table hierarchy for rules until it finds one, then stops looking. So in the case of a task field like short_description, the system would look for rules in different ways based on where that field was being used. When looking at an incident, the system would look for rules in the following order: incident.short_description, task.short_description, *.short_description When looking at a change_request, the system would look for rules in the following order: change_request.short_description, task.short_description, *.short_description What this means is that a rule at a lower level in the hierarchy can override a rule on a base table. Perhaps I am allowed to change the short_description on incidents, but not on change requests. This lends itself to a number of best practices. Contextual Security Manager Best Practices Secure as high in the hierarchy as you can It's easier to secure short_description on task than it is to secure it on incident, and change_request, and problem, and sc_request, etc. There's only one rule to write for one thing, and if you have to change it, there is only one rule to change. You don't lose any flexibility here, since if you end up needing to secure incident differently, you can still put a specific rule on incident.short_description and still have all the other extensions use the rule on task.short_description Use as few rules as possible This is a corollary to the previous suggestion, but fewer rules are easier to manage. There's no real efficiency difference in terms of processing time between having a rule in incident, another one on problem, and third one on change_request vs. having a single rule on task, but there is a big efficiency different in terms of human time in creating and maintaining the rule base. But not too few If you do find yourself needing different security constants for incident.short_description vs. task.short_description, you could conceivably handle the difference with a scripted rule on task.short_description that checked the class name of the current record and responded differently in each case. While such an approach works, it usually results in fairly large and complicated script rules (especially after they've gone through multiple revisions). You'll usually have an easier-to-manage rule base if you put one simple rule on task and a second simple rule on incident.