Documentum → Veeva Notes

From Documentum ACLs to Veeva Vault Security

Why Permission Sets Are Not ACLs. A Permission Set looks like the obvious equivalent of an ACL. It is not.

If you have spent years working with Documentum, one of the first security questions you may ask when moving to Veeva Vault is: where is the ACL?

It is a reasonable question.

In Documentum, the ACL is one of the first places a developer looks when troubleshooting access to an object. Find the object, identify its ACL, inspect the ACL entries, resolve user and group membership, and determine the resulting permit.

When you first encounter Vault, a Permission Set looks like the obvious equivalent. It is not.

A Permission Set is an important part of Vault security, but treating it as the Vault version of a Documentum ACL creates the wrong mental model. Vault distributes access control across several layers, including the user’s license and security profile, Permission Sets, document roles, the document’s current lifecycle state, and the permissions configured for those roles in that state.

The useful shift is this:

Documentum encourages you to ask which ACL controls this object. Vault encourages you to ask which security layer allows, or prevents, this user from performing this action on this document.

That difference matters when you start debugging real access problems.

The Documentum mental model

For a typical Documentum object, the security relationship is relatively easy to visualize:

dm_sysobject
  |
  +-- acl_domain
  +-- acl_name
         |
         v
       dm_acl
         |
         +-- user / group entries
         +-- permit

The object identifies an ACL through acl_domain and acl_name. The ACL contains access entries for users or groups, and those entries contribute to the effective permission for a particular user.

There are additional rules and details, of course. Group membership matters. Owner, group, and world permissions can matter. Extended permissions and application behavior can add more complexity.

But the ACL remains a natural center of gravity.

When a user says, “I can see this document but I cannot modify it,” a Documentum developer will often start with questions such as:

• Which ACL is attached to the object?
• Is the user explicitly listed?
• Which groups contain the user?
• What permit is granted to those groups?
• Is another ACL entry changing the effective result?

That habit is deeply useful in Documentum. It becomes misleading in Vault. See ACL permissions (1–7) and ACL vs permission set for the Documentum side.

A Permission Set is not a Vault ACL

The easiest mistake is to create this mapping:

Documentum ACL  <-->  Veeva Permission Set

Delete that mapping.

A Vault Permission Set is much closer to a definition of a user’s general capabilities within Vault than to an access control list attached to one specific document.

Permission Sets can grant application, administrative, object, tab, and other categories of permissions. Vault applies Permission Sets to users through Security Profiles.

That answers questions such as: is this kind of operation generally available to this user?

It does not, by itself, answer: can Alice edit Document 123 while that document is in Approved state?

The distinction between those two questions is the beginning of the Vault security mental model. Think of a Permission Set as participating in the user capability layer. Access to a particular document requires another part of the model.

So what is the Vault equivalent of an ACL?

There is no single equivalent. That is probably the most important point in this article.

A Documentum ACL conveniently brings together two ideas: who has access, and what that user or group can do. Vault separates those concerns more explicitly.

For document-level security, a useful simplified model is:

          Veeva Vault document security

  WHO                              WHAT
   |                                 |
   v                                 v
Document role                 Lifecycle state
/ Sharing Settings                   |
   |                                 v
   |                          Security matrix
   |                        (permissions by role)
   |                                 |
   +---------------+-----------------+
                   |
                   v
             Effective access

A user or group can be assigned to a document lifecycle role such as Owner, Editor, Reviewer, Viewer, or a custom role.

The document’s lifecycle then defines what that role is permitted to do in each lifecycle state. That second part is critical.

The same user can remain in the same role on the same document and still have different capabilities after the document moves to another state. This is one of the places where the ACL analogy starts to break.

License type and security profile can restrict access, while document roles and state-specific security determine what a user can do on a particular document.

A simple example

Assume Alice is a regulatory author.

In Documentum, imagine a document using this ACL:

ACL: regulatory_document_acl
  regulatory_authors     WRITE
  regulatory_reviewers   READ
  dm_world               NONE

Alice belongs to regulatory_authors. For a simplified example, the reasoning is straightforward:

Alice
  |
  v
regulatory_authors
  |
  v
WRITE

The ACL is the obvious place to start when explaining why Alice can modify the document.

Now consider a similar business situation in Vault. Alice might have:

For the Draft lifecycle state, the Author role may be configured to allow operations such as editing fields or uploading a new version. So Alice can work on the document.

Later, the same document reaches Approved. Suppose the lifecycle security configuration for Approved allows the Author role to view the document but no longer edit fields or upload a new version.

Notice what did not change: Alice is still Alice. Her Security Profile did not change. Her Permission Sets did not change. She may still be in the Author role. Yet her ability to modify that document changed.

Why? Because the document lifecycle state changed, and the permissions associated with the Author role in that state are different.

Vault explicitly supports state-specific permissions for document lifecycle roles through its security matrix. For a Documentum developer, that is an important shift.

The layered model

A better way to reason about Vault access is to start from the question the user is trying to answer. For example: can Alice edit this document? Then work through the layers:

Alice
  |
  v
License type
  |
  v
Security Profile
  |
  v
Permission Sets
  |
  v
Document role(s)
  |
  v
Lifecycle state
  |
  v
Role permissions in the current state
  |
  v
Edit allowed?

This is intentionally simplified, but it gives a Documentum developer a much better starting point than looking for a single Vault object equivalent to dm_acl.

The upper part of the diagram answers questions about what Alice is generally capable of doing in Vault. The lower part answers questions about Alice’s access to this particular document in its current state.

License type, Security Profile, and document role are separate contributors to document access, with more restrictive license or Security Profile settings able to override access that a document role might otherwise grant.

Where the analogy breaks

This is where translating Documentum terminology directly into Vault terminology becomes dangerous.

1. Permission Sets are not attached to individual documents

A Documentum ACL has a direct relationship with the secured object. A Vault Permission Set belongs on the user-capability side of the model. It is associated with users through Security Profiles rather than being attached to an individual document as that document’s access list.

2. Document roles are document-specific

Vault document lifecycle roles provide a mechanism for document-specific access control. A user can be an Author on one document and a Viewer on another. That makes roles an important part of the answer to: why can Alice edit this document but not that one?

3. Lifecycle state is part of the security calculation

This is probably the biggest conceptual difference. In Vault, permissions available to a document role can change with the document’s lifecycle state. Draft may permit editing. Approved may permit viewing but not editing. The role did not necessarily change. The user did not necessarily change. The state changed. Vault lifecycles deliberately combine process behavior and state-specific security.

4. Some actions have another security layer

Vault also has Atomic Security, which allows more granular control over certain workflow and document lifecycle actions by role and lifecycle state.

Atomic Security should not be thought of as yet another replacement for an ACL. It is another example of why Vault security is better understood as layered rather than object-centered.

For example, two workflow-start actions may exist in the same state while a particular role is allowed to use only one of them. This is useful functionality, but it also reinforces the main point: there is no single Vault object you can inspect and say, “This is the complete security definition for this document.”

A better troubleshooting habit

When a Vault user reports “I can see the document, but I can’t do X,” do not immediately open the Permission Set and assume that is where the answer must be. Instead, determine which layer controls X.

A practical investigation order is:

1. Check the user’s license type.
2. Check the user’s Security Profile and relevant Permission Sets.
3. Identify the user’s role or roles on the document.
4. Check the document’s current lifecycle state.
5. Check the security matrix for those roles in that state.
6. If the problem involves a specific lifecycle or workflow action, check Atomic Security.
7. If the issue is field-specific, check whether field-level security further restricts editing.

This last point is another good example of Vault’s layered approach. Field-level security can further restrict document fields, but it cannot grant a user document-level access that the user did not already have.

The goal is not to memorize every Vault security feature. The goal is to identify which layer owns the decision you are debugging.

Documentum vs Vault: the mental mapping

A rough mapping is useful as long as it is treated as a learning aid rather than a one-to-one translation. The dangerous word in this table is closest. None of these should be read as “X in Documentum equals Y in Vault.” They are landmarks for navigating a different security architecture.

The mental model to keep

For Documentum, a useful first question remains: which ACL controls this object?

For Vault, replace it with: what action is the user trying to perform, and which security layer controls that action?

That small change in questioning prevents a surprising amount of confusion.

If the issue is broad application capability, look toward the user’s license, Security Profile, and Permission Sets.

If the issue is access to a particular document, look at document roles, Sharing Settings, the current lifecycle state, and the role permissions configured for that state.

If the issue is a specific workflow or lifecycle action, Atomic Security may also participate.

The important thing is not to search for “the Vault ACL.” It does not exist. And once you stop looking for it, Vault security becomes considerably easier to reason about.