A context defines how sealed content can be accessed by users and groups.
Contexts are created exclusively from context templates. Nothing in a context can deviate from the definitions set up in the context template. Contexts cannot change the role definitions defined in the context templates.
Note:
Changes made to a context template or role are immediately reflected in the contexts that were created from them.Contexts are created by domain administrators and domain managers, but each context is managed by its context manager, who is usually a business owner (rather than part of the IT organization). Context managers assign roles to users (see Section 3, "Working with Roles"). Users that have not been assigned as context managers cannot assign roles.
Contexts are normally made visible to inspectors, in read-only mode. Inspectors can use their read-only capability to make investigations and to answer queries. Inspectors cannot elevate permissions of users, groups, or special users.
In exceptional circumstances, a context can be made invisible to inspectors. This should be done rarely, for example for contexts relating to highly sensitive mergers and acquisitions.
Because contexts continue to be affected by changes made to the context templates from which they are derived, it is important that domain administrators are normally also made inspectors. This is to enable domain administrators to see all contexts on the server, and so be able to tell which contexts will be affected by changes made to context templates. For the same reason, it is important to make all contexts visible to inspectors unless secrecy is absolutely essential.
A context can be associated with multiple trusted contexts. These are contexts for which certain sealed document activities are allowed. The most common reason to set up trusted contexts is to allow copying and pasting between documents in the current context and documents in the trusted contexts.