Documentum → Veeva Notes

From dm_document to Vault Documents: What Maps and What Doesn't

Similar hierarchies, different object models.

When a Documentum developer first starts working with Veeva Vault, some of the concepts feel immediately familiar. Documentum has document types. Vault has document types. Documentum types inherit attributes. Vault document types inherit fields. Both systems manage metadata, versions, lifecycle behavior, security, content, and renditions.

So this mapping is not unreasonable:

Documentum                         Veeva Vault
dm_document                 <-->   Document
custom subtype              <-->   Type / Subtype / Classification
attributes                  <-->   fields

In fact, parts of that mapping are genuinely useful. The mistake is not making the analogy. The mistake is assuming it continues all the way down.

Mental model

Documentum and Vault both organize documents through hierarchical configuration and inheritance.

But Documentum’s document hierarchy is part of a persistent object type system, while Vault’s Type / Subtype / Classification hierarchy is the configuration model for documents queried through the common documents target.

Some concepts map well. Their implementation models do not map one-to-one. That distinction explains several differences that otherwise look arbitrary: why VQL queries document types differently, why Vault document IDs behave differently across versions, and why Vault Objects should not automatically be treated as another Documentum custom type.

Start with what really does map

It is worth establishing this first, because the two systems are not completely different. A simplified Documentum hierarchy might look like:

dm_object
  |
  v
dm_sysobject
  |
  v
dm_document
  |
  v
custom_document
  |
  v
custom_subtype

Documentum persistent types form an inheritance hierarchy. A subtype inherits the properties of its supertype, and dm_document itself inherits its properties from dm_sysobject.

Now consider a simplified Vault document hierarchy:

Base Document
  |
  v
Document Type
  |
  v
Subtype
  |
  v
Classification

Vault also has real inheritance here. If a field is applied to a document type, child types inherit it. Lifecycle configuration can also inherit down the hierarchy, and the document-type hierarchy is used for other settings including rendition types and some security-related configuration.

So this is a valid first approximation: a Documentum custom type hierarchy is conceptually similar to a Vault Type / Subtype / Classification hierarchy. A Documentum developer’s instinct that “a more specialized document classification inherits configuration from a more general one” transfers surprisingly well. But now we reach the important part.

The hierarchies do different jobs

In Documentum, a custom document type is an actual persistent repository type. Suppose you define:

dm_document
  |
  v
custom_document
  |
  v
custom_subtype

Then custom_subtype is a queryable type in the Documentum repository. DQL can naturally say:

select r_object_id, object_name, sop_number
from custom_subtype

The type in the FROM clause is part of the object model itself. The type system determines which properties the object inherits, and an instance belongs to that persistent type hierarchy.

Vault document classification behaves differently at the query-model level. A Vault SOP may have Type = Controlled Document, Subtype = Procedure, Classification = SOP. But VQL does not normally query a separate sop document object as its FROM target. Instead, documents are queried through FROM documents, and their classification is represented by fields such as type__v, subtype__v, classification__v.

select id, name__v
from documents
where toname(type__v) = 'sop__c'

This gives us the first important distinction:

DOCUMENTUM
  custom_subtype
       |
       v
  persistent type
       |
       v
  FROM custom_subtype

VEEVA VAULT
  documents
     |
     +-- type__v
     +-- subtype__v
     +-- classification__v

Both have hierarchy. But the hierarchy occupies a different place in the platform architecture.

So is a Vault document type like a Documentum type?

The best answer is: yes conceptually, but not mechanically. That is more useful than either extreme (“they are the same” or “they have nothing to do with each other”).

They solve many of the same configuration problems. Both can help determine which metadata applies, which fields are inherited, which lifecycle behavior applies, how documents are categorized, and which additional configuration becomes available.

But they are exposed differently to developers. A Documentum type is part of the persistent object type hierarchy. A Vault document type is part of the document classification/configuration hierarchy underneath the common Vault document model. That distinction becomes especially visible when you write queries or integrations.

Documents and Vault Objects are another important boundary

The word object creates another trap for Documentum developers. In Documentum, object-oriented repository thinking is everywhere:

dm_object
  |
dm_sysobject
  |
  +-- dm_document
  +-- dm_folder
  +-- ...

Once you have worked with Documentum long enough, the natural question becomes: “What type of object is this?”

Vault also has something explicitly called Vault Objects. For example:

select id, name__v
from product__v

At first glance, it is tempting to think Vault Object = Documentum custom object type. Sometimes that comparison helps at a very high level, but again it should not become a structural assumption.

VQL treats documents and Vault Objects as distinct query targets.

select id, name__v
from documents

select id, name__v
from product__v

Documents, Vault Objects, users, events, relationships, and other entities are different VQL query targets. A useful developer model is therefore:

                 VEEVA VAULT
        +-------------+--------------+
        |                            |
        v                            v
    Documents                   Vault Objects
        |                            |
 managed content              application data
        |                            |
 Type/Subtype/Classification   product__v
        |                      study__v
    versions                   custom_object__c
        |
    content

Do not try to place both branches underneath an imaginary Vault equivalent of dm_sysobject. That construct is not necessary to understand Vault.

Version identity is where the difference becomes very clear

This is probably the strongest example of why concept translation works better than field translation.

Documentum

A Documentum version tree contains multiple document objects. Each version receives its own r_object_id, while every version in the same tree shares i_chronicle_id. The chronicle id identifies the root of the version tree and remains the same as new versions are created. See r_object_id, i_chronicle_id, and versions.

i_chronicle_id  (shared)
  1.0  r_object_id  (its own 09… id)
  1.1  r_object_id  (a different 09… id)
  2.0  r_object_id  (another 09… id)

So Documentum provides a useful distinction: which exact persistent version object (r_object_id), versus which version tree (i_chronicle_id).

Vault uses a different identity model

Now query all versions of a Vault document:

select id, major_version_number__v, minor_version_number__v
from allversions documents

A result can look conceptually like the same id on multiple versions, distinguished by major/minor. Vault APIs likewise identify a particular version using document id + major version + minor version, for example /documents/{doc_id}/versions/{major}/{minor}.

Vault
  document id = 6
      1.0
      1.1
      2.0

The document ID remains associated with the document while version coordinates identify a particular version.

But notice what this table does not say. It does not say i_chronicle_id equals Vault id. They are conceptually useful counterparts when reasoning about version identity. They are not the same implementation.

This is why r_object_id = Vault id is a bad mapping

At first glance, Documentum r_object_id and Vault id looks obvious. Both fields are called IDs. But they answer different questions once versioning enters the picture.

In Documentum, r_object_id identifies a particular persistent version object. In Vault, id continues to identify the document across its versions. Same name category, different identity semantics.

This is one of those differences that matters much more in migration code than it does in a product overview. If you migrate data assuming that Documentum r_object_id maps to Vault document id as the conceptual identity mapping, you may be carrying version-level identity into a system whose document identity is modeled differently.

A migration design needs to decide whether the source identity being preserved represents a document series, an individual version, or both. That is a modeling question, not a field-renaming exercise.

Metadata inheritance: more similar than it first appears

This is the part not to overstate as a difference. Suppose Documentum has dm_document → custom_document → custom_subtype, and custom_document defines product, country, effective_date. A child subtype inherits those attributes.

Vault can produce a very similar developer experience. Fields attached higher in the hierarchy (Base Document → Controlled Document → Procedure → SOP) are inherited by child document types. A field applied to a document type is inherited by its child types.

So this is a legitimate mapping: Documentum property inheritance corresponds conceptually to Vault document field inheritance. The important distinction is not that one system has inheritance and the other does not. It is what is being inherited through which model: Documentum persistent type inheritance versus Vault document configuration hierarchy. That is much subtler, and much more accurate.

Lifecycle inheritance has a similar pattern

The same point applies to lifecycle. Vault lets a lifecycle selected at a parent document type level be inherited by child levels, with child types able to override that selection.

Base Document
    General Lifecycle
        |
        v
Document Type
    inherits General
        |
        v
Subtype
    overrides with Specialized
        |
        v
Classification
    inherits Specialized

So again, Documentum developers should not approach Vault as if all familiar concepts disappeared. Many of the ideas survive. What changed is how the platform organizes them. That is the recurring theme of this series.

Querying reveals the architecture

This is why the previous article on DQL vs VQL connects directly to this one.

Documentum:

select r_object_id, object_name
from custom_subtype

The type itself appears in FROM.

Vault:

select id, name__v
from documents
where toname(type__v) = 'sop__c'

The classification is part of the document’s metadata. Now compare Vault application data:

select id, name__v
from product__v

Here, product__v is the VQL query target. That tells a Documentum developer something important about the Vault model without reading any architecture diagram: Document Type is not Vault Object Type. They are different configuration/data concepts even though both involve fields and named business entities.

Where the analogy works

This section matters just as much as where the analogy breaks.

1. Both systems have document hierarchies. Documentum custom types can extend document types. Vault provides Base Document → Type → Subtype → Classification.
2. Both support inherited metadata. Documentum subtypes inherit properties. Vault child document types inherit fields.
3. Both attach behavior to document classification. Lifecycle and other document behavior can depend on the type/classification structure.
4. Both let developers reason from general to specific. A broad document definition can establish behavior inherited by a more specialized document definition.

This part of a Documentum developer’s mental model survives very well.

Where the analogy breaks

Now the important limits.

1. A Vault Document Type is not a persistent VQL type. Documentum: FROM custom_subtype. Vault: FROM documents WHERE …. That is not merely syntax. It reflects a different model.
2. Vault Objects and Vault Documents should not be collapsed into one hierarchy. Vault Objects such as product__v, study__v, custom_object__c are distinct VQL query targets from documents. Do not invent a conceptual Vault dm_object parent just because that model feels familiar.
3. Version identity is different. Documentum: version → unique r_object_id, series → shared i_chronicle_id. Vault: document → id, version → id + major/minor. This matters in integrations and migrations.
4. Type inheritance and document classification are similar, but not identical mechanisms. Both systems inherit metadata and configuration. But one belongs to Documentum’s persistent object type system; the other belongs to Vault’s document configuration model. The similarity is real. So is the distinction.

A better mental mapping

Instead of forcing dm_object = Vault Object, dm_sysobject = ?, dm_document = Document, custom type = Document Type, r_object_id = id, use this:

The key word is comparison, not equivalent.

Why this matters during migration

This difference becomes especially important when moving from Documentum to Vault. A mapping spreadsheet can easily start like this:

Documentum                 Vault
object_name          →     name__v
r_object_id          →     id
custom type          →     document type
attribute            →     field

The first and last mappings may be straightforward. The middle ones require more thought.

For example, a custom Documentum type might represent a Vault document Type, a Subtype, a Classification, a Vault Object, or some combination of document classification and object references. Likewise, r_object_id may be useful as a migrated legacy identifier, but it should not automatically become your conceptual Vault document identity.

The better migration question is: what business concept did this source construct represent? Then map that concept into Vault. Not: which Vault field has the closest-looking name?

A better question for Documentum developers

When learning Vault, this question is natural: what is the Vault equivalent of X? Use it. But do not stop there. Follow it with: what responsibility did X have in Documentum? And: how does Vault represent that responsibility?

• Instead of “What is the Vault equivalent of i_chronicle_id?” ask: how does Vault identify a document across multiple versions?
• Instead of “What is the Vault equivalent of my custom dm_document subtype?” ask: did that source type represent document classification, application data, or both?
• Instead of “Where is the Vault dm_sysobject?” ask: how does Vault model the specific capability I used dm_sysobject for?

Those questions produce much better designs.

The mental model to keep

If you remember only one diagram from this article, use this:

DOCUMENTUM
  persistent object type hierarchy
  dm_object
     |
     v
  dm_sysobject
     |
     v
  dm_document
     |
     v
  custom document types
     |
     +-- inherited properties

VEEVA VAULT
                    Vault
                      |
         +------------+------------+
         |                         |
         v                         v
     Documents                 Vault Objects
         |                         |
 document configuration     application data
         |
    Base Document
         |
       Type
         |
     Subtype
         |
  Classification
         |
 inherited fields/config

The lesson is not that Documentum and Vault are completely different. They are not. And it is not that Vault is just Documentum with new names. It is not that either.

The useful middle ground is: many of the document-management concepts map surprisingly well. The architecture underneath those concepts has changed.

Once that distinction becomes clear, several things become easier at the same time: DQL vs VQL makes more sense, Document Type vs Vault Object makes more sense, version identity makes more sense, migration mappings become less mechanical, and you stop looking for one-to-one replacements where none are needed.

For a Documentum developer learning Vault, that is the object-model shift worth making.