Now that you have seen the power of PSTs, the next question you probably have is when should PST be used (vs regular ACLs).
Based on my experience, PSTs should be used when the following conditions exist – especially if ALL the conditions are true:
- Your company/organization has well defined groups/roles. Examples of groups are departments and contractors. Examples of roles are content authors, managers, and vice presidents.
- You plan on implementing lifecycle security. This means that permissions on documents will change over the lifecycle of the document.
- You want to actively manage permissions at an enterprise level. This is important from an application support perspective. Typical end users are not knowlegable enough about Documentum security to properly dictate what permissions should be assigned to documents.
PSTs should not be used (or used sparingly) in the following situations:
- Your organization is not well defined. Without some level of organization, defining meaningfull alias sets becomes very difficult.
- Your organization is small and/or you do not plan to use lifecycle security. The number of PSTs or alias sets is limited, so the additional layer of complexity outweighs the benefit of PST.
- Your business processes are not well defined and your security requirements are ad-hoc in nature. If the user requires the ability to grant/revoke permissions on documents at will, then you cannot manage security at a central level.
There are probably other circumstances where PSTs can be a “great friend” or an “evil foe“. I am definitely interested to hear how other architects use PSTs or have tried to use PSTs and failed given the environment they were working in.