Understanding the functionality of versioning can be tricky at first. Other than the version name and description, the other version components are a little vague, but once you understand how they work together it can become very useful. I’m going to go through the different components of a version, and explain how they work together. I’ll go over:

  1. Version Type
  2. Version Status
  3. Saving Versions
  4. Load Status

When you sign into DRM, on the main browse menu shows the versions in the application. I’m not going to go into much detail about Version Name and Description; the Version Name is whatever you want to call your version – Production, ABC_Company_January2010, etc. Version Description is what it means: production, test, a specific hierarchy grouping – whatever you need to distinguish it from the other versions in your application.


After version name and description, there is the Type. There are 3 different options for this: Normal, Baseline, and As-Of.

  • Normal: this is a regular version that can be edited, depending on the status. The status of it can also be modified.
  • Baseline: this is the starting point of when the version was saved. Think of it as the original copy, or v1, of the metadata, that you can use as a reference when analyzing changes.
  • As-Of: This is similar to baseline, it is like a snap-shot of the version at a certain place in time or transaction ID. Also useful as a reference of what has changed in the version since that particular date.

Then, depending on the version type, the version will also have a Status category. There are 4 statuses, but all the options are not available for all of the version types.

  • Working: This is available for Normal versions only. It means the version is in editable mode and is still a work in progress. Anyone with proper security can edit and browse the version.
  • Expired: Baseline and As-Of versions default to this status and cannot be changed, and Working versions can also be set to have this status. Expired versions cannot be edited (however, working versions can have their statuses re-set to have a working status again). Actually, only Data Managers  (security role) can see Expired versions.
  • Finalized: This is a non-editable status for the working version, meaning it cannot be edited and it is in its final state.
  • Submitted: This is a version that is no longer ‘open’ for any user with editing power to edit, however the owner of the version or the Data Manager role may edit the status.

Next, there is the Saved category. This tells the user if the version they are working in is committed to the DRM database or it is working in memory. Things that are just in memory can be worked in until the DRM application is restarted.

Please note though, if you have a version that you are working in that cannot be re-imported or re-derived easily if it were lost, please save the version. If your Hyperion environment were to get restarted or suddenly crash, you may lose your work.

Well, you ask, why isn’t just everything saved to the database? What’s the point if I am going to just lose all my work anyway? Well here’s an example:

Say you have a large product hierarchy at your organization, which is loaded from an external system. At quarter end, you need to get new nodes and property changes into your existing hierarchy in your production version of DRM, without losing any legacy members that may no longer be in the external system. In order to keep the size of your database manageable, load the new product hierarchy into DRM via import into a temporary version, and do not save the temporary version. Then, create a blender to blend the new nodes and updated properties into the production version.  Once this is complete, you can delete the temporary version without significantly increasing the size of your DRM application. Plus, you don’t really need to keep the imported temp hierarchy, you just need to grab the changes.

Lastly there is the Load status of the version. This tells the user which versions have been loaded to memory, which is ready to use or browse, or if they are just initialized. Initialized means they reside in the database but are not yet pulled into memory. If you want to us a version in DRM that is initialized, you have to right click it and select “Load” in order to Browse, Import, Export, Query, Blend or Audit the version.

Note: If you have a lot of versions that have several hierarchies in them, its best to not have all the versions to be loaded, it will slow down your application and may make it a bit frustrating to work in. Just have the versions that are pertinent to your current task loaded into memory. Any versions that are for historical or audit purposes (i.e. what Year-End 2010 hierarchies were), keep them as Initialized until you’d need to revisit them.

Hope this helped uncover some of the basics of the versions in your DRM application and how they are used. In a few weeks I’ll go over Versioning Lifecycle and best-practices of Versioning in DRM.