When implementing DRM, there are a few properties I like to add in to add visibility to changes within hierarchies, that can be viewed within the property panel when they are browsing the hierarchy itself. This adds a little more context, without having to run an Audit report.

The properties are CreatedDate, CreatedBy, LastUpdatedDate, and LastUpdatedBy. These are custom Property Definitions, created manually (not with stock XML property imports), that add some insight – as they tell you when a node was added, who added it, and the same for any changes.

Changetracking

I also add a Property Category called “Change Tracking” – and add these properties to that dropdown. This separates the properties from other Property Categories, but is easily accessible to the user (as long as the user is provisioned to the “Change Tracking” Property Category or has the correct Node Access Group).

To create a new property definition in DRM, go to Administer > NewProperty Definition and add the properties by choosing the settings. When you select the property to be Derived by a Formula, it will unlock a “Parameters” tab. Go to this tab and either build or type in the code detailed below. This code is a DRM specific formula language (its pretty similar to Excel code, but has its own functions).

Changetracking_Prop_Param

 

PropertyCategorySelect.png

Set up the properties using these parameters:

  • CreatedDate
    • Global Node
    • Derived Formula
    • Data Type: Date/Time
    • Parameters:
      • AddedOn(Core.Abbrev)
  • CreatedBy
    • Global Node
    • Derived Formula
    • Data Type: String
    • Parameters:
      • AddedBy(Core.NodeAddedBy)
  • LastUpdatedDate
    • Global Node
    • Derived Formula
    • Data Type: Date/Time
    • Parameters:
      • ChangedOn(Core.NodeLastChangedOn)
  • LastUpdatedBy
    • Global Node
    • Derived Formula
    • Data Type: String
    • Parameters:
      • ChangedBy(Core.NodeLastChangedBy)

One consideration – do not check the “Override’ option on any of these Property Definitions, as you do not want users to override the derived value.

Remember when adding Property Definitions and Categories to test them first. These properties should be fairly straight forward, and do not interfere with any other existing configurations.