Data Protection Explained

In my very first post, I listed the Top 10 Out-of-the-Box features of FDM. Weighing in at #5 was Data Protection.  Of all of the amazing features in FDM, this can often rank highest for HFM end users – even those that never log into FDM.

So what is data protection and why is this such an important feature?  Let’s explore.  During a normal month end close cycle, a trial balance is often loaded multiple times.  The following methods which can be used to load data to HFM:

  • For each entity in the data file to be loaded, all accounts, intercompany partners (ICP) and custom 1-4 are cleared for the period and year to be loaded.
  • Each unique intersection in the data file is updated in HFM. For example, an intersection was previously populated with a value of 100. In the data file, the value for that same intersection is 150. The value is updated to 150 when the data file is loaded. However, any intersection not in the data file is left unchanged.
  • Functions the same as Replace except that intersections to which the user does not have access are not updated.
  • For each intersection in the data file, the value is added to the existing value in HFM for that intersection. Using the Merge example, if an intersection has a value of 100 and a data file with a 150 value for that same intersection is loaded with Accumulate, the ending value in HFM will be 250.

Almost exclusively, data is loaded to HFM using the Replace load method.  At the risk of wielding the “best practice” hammer, loading in replace is considered an industry best practice.  Here’s why, when loading with replace, all intersections for a given entity are cleared.  This is important because within a given entity, data may be reclassed out of an intersection and therefore no longer exist in the data file.  If data is loaded using Merge, the HFM record would persist and the resulting financial results would be over/understated by the balance in that intersection.  The only way this “reclassed” intersection will be systematically cleared is to use one of the replace load methods.

So hopefully you can see the case for using Replace when loading data.  Let me take a moment now to address the most common reason why Merge is sometimes used.  Do either of the following statements (or some variation thereof) sound familiar?

  • If we load this stats file through FDM using replace, we’re going to clear our trial balance data
  • There is manually keyed information in HFM that gets overwritten when we load using replace

If the answer to either of the above is Yes, then data protection may be able to enhance your application and thereby your data quality.  Ok, I’m sold, what is this fabled data protection?

Data Protection is an out of the box feature of FDM that allows data to be loaded to using replace but prevent identified intersections from being cleared – even if they are not part of the data set being loaded by FDM.

Let’s take a classic example.  1 user, let’s call him Tony, uses FDM to load trial balance information.  The trial balance is loaded in replace mode *until* the another user from the accounting team, let’s call her Carol, enters the fixed asset detail in an HFM web form. Without data protection, after Carol enters the fixed asset detail, if Tony were to load the trial balance using replace he would overwrite the manually keyed fixed asset data and likely make Carol very unhappy.

With data protection, Tony can reload the trial balance using replace even after Carol manually enters her fixed asset details.  So how does it work when we all know that replace clears all intersections?  Great question and bear with me as I introduce a little technical detail.

When data protection is enabled, FDM will still clear all intersections for the entity.  However, prior to the data load, FDM reaches into the HFM database and extracts records (based on the data protection settings) that need to be “protected.”  Those records are then appended to the data file that FDM produces and the data is loaded.  Technically, the protected intersections are cleared as part of the data load.  However since these intersection were appended to the data file, they are reloaded to HFM and the manually key data is maintained/protected.

If you’re still reading, you’re likely excited and want to leverage this.  The good news is that in the right situation, this can be implemented in a matter of minutes.  Let’s take a quick moment to review the settings to enable Data Protection.  Data protection is controlled by the integration settings of the HFM adaptor.  Under the integration settings,

  1. Enable Data Protection
  2. Set the Data Protection Value
  3. Select the Data Protection Operator

The first step is pretty obvious.  Let’s talk about steps 2 & 3.  The Data Protection Value specifies the base level dimension member used to identify the records to extract from HFM.  This is used in conjunction with the Data Protection Operator.  The Operator has 2 valid values, Equals (=) or Not Equals (<>).

Let’s take a real world example.  Tony loads data through FDM to the HFM Custom4 dimension member GeneralLedger.  Carol inputs Fixed Asset data to the custom4 member ManualEntry.  In this example, the data protection settings could be:

  • Value: ManualEntry; Operator: Equal (=) OR
  • Value: GeneralLedger; Operator: Not Equals (<>)

So which is the right choice.  The answer is, if you hadn’t guessed, it depends.  A lot depends on your HFM metadata and where data is populated.  If you are unsure, you can always do a quick test in test environment or an alternate scenario/period in your application.  As with any system change, let me stress the importance of proper backups prior to making and testing changes.

Finally, let me take a moment to address the 2 most common questions I am asked about data protection:

  • No.  However, FDM uses the VBScript Instr function to determine if the Protection Value is found in the HFM record.  Creative thinking and metadata design can often address the “need” to protect multiple values.
  • You don’t.  Because FDM uses the Instr function to search the entire record, it doesn’t matter in which dimension your value is.  If the protection value is found, the record is protected (or not protected).

I hope this posting has introduced you to a key piece of functionality.  As with all out of the box features that I highlight, this functionality is currently available to you (if you are integrating with HFM) – it does not require any additional licensing.  I hope you will explore how enabling Data Protection can add value to your application.  As always, questions and comments are welcomed.

This entry was posted in Out of the Box Functionality and tagged , . Bookmark the permalink.

2 Responses to Data Protection Explained

  1. Andriy Golovchenko says:

    Thanks Tony, good article. Just came to the conclusion that whether to use <> or = for ‘GL’ depends on a business process. If GL is what might change then one would use GL to save all other data and vice verse. In our recent case, we had to load HeadCount for LPP after GL has been loaded. Looks like Merge is our best option in this particular case (as HeadCount is the only possible account dimension name which will be loaded once and after GL data is already in the system). Otherwise switching back and forth GL to =GL is probably not the best solution. But as alway, it depends… Thanks again for keeping FDM community in tune! :)

    • Tony Scalese says:


      As you pointed out, many things in the EPM space are process dependent. This posting is not intended to be a “how to” guide but is instead intended to empower the user with knowledge of how the process works so that they can apply that to their environment and processes. I can, with a high degree of confidence, say that the situation you describe should not require the use of Merge. You might want to take another look at things (hint – look at the C4 maps for your headcount accounts).

Leave a Reply