How to automate subsets

whitby

How to ensure your Center of Excellence keeps on top of subset management

One of the easiest things that can go wrong in a model is when subsets get out of sync. In larger models you may have multiple subsets on large lists and keeping track of them all can quickly become very difficult. For example, what happens when someone deletes the list members? Do you know how to reconstruct the subsets?

Here are four rules you can follow to prevent any subset nightmares and make your life (and the lives of your Anaplan administrators) massively easier in the long run:

1. Define your subsets
2. Use a consistent approach
3. Automate
4. Status reporting

Define your subsets

The first step in defining your subset is to create it with a proper name using the naming convention recommended in the Planual 1.06-01 Subset Naming Convention

 

 

- A prefix (ls, sub, ss) to indicate that the list is a subset of a larger list.
- The name of the parent list.
- A colon followed by a description of the list subset.

 

 

In our example, we are going to create and manage a subset of a Country list that is available for planning (meaning we create our subset with the name 'ss Country: Available for planning').

Now we get on to how to manage our subset. It may seem obvious, but I have come across many models where subsets are managed manually in a dashboard with or without instructions provided. A business definition will always exist for a subset. Therefore, we can codify it. If a rule is complex, then you can break it up into its component parts. A country is available for planning in our example if it is either:

1. Our headquarter country Germany
2. Has been selected for planning in our Country Selection input module

 

Below we can see a definition for our 'Country: Available for planning?' that is driven by a set of two upstream rules:

Note:

• The 'Headquarters?' line is referencing a Constants module with a line item named Germany (not a constants list).
• In this example, the two rule line items are used elsewhere in the example model. If they weren't, we could optimize this formula by embedding all the individual rules in the subset definition and remove the daisy chaining we see here (at the cost of readability). 

Use a consistent approach

No, I don’t mean publish them all as lists on the same dashboard. What I mean here is consistency with how subsets are defined. Just because a subset can be loaded from anywhere in the model doesn’t mean it should be. Subsets should be defined in the same way for every subset and for every list. Anaplan’s D.I.S.C.O. methodology gives us a perfect place for that to happen and that is in the System module for the list in question:

Following this approach means that when an administrator needs to check a subset they know straight where to go.

If you have a more complex calculation that feeds into a subset (for example, you need to check if there is any transactional data related to a list member) then you can use calculations elsewhere to feed the systems module. The key is to keep the subset definition in the same place.

Automate

By this point we:

• Have our subset definitions
• Know where to find our definitions

So why are we still manually updating the subset? As Anaplan modelers, we can automate the update process. Using our country example, it can be done using three line items (note the 'Applies To' for the 'Subset Test' item uses our subset). 

	Line Item	Data Type	Formula	Applies To
Rule	Available for planning?	Boolean	Business rule to apply e.g. ‘Headquarters? OR Selected for planning?	Country
Subset Test	Available for planning – Subset?	Boolean	TRUE	ss Country: Available for planning
Update check	Update Required?	Boolean	‘Available for planning?’ <> ‘Available for planning – Subset?’	Country

The rules as they appear in the systems module in Anaplan are shown below:

The image below shows how this appears once built; the business rule in the first line, the subset test in the second line (controlled by the use of a subsidiary view), and an update check for where there is a difference.

The 'Update subsets?' line item is important for two reasons. First, it means that, when we build our update job, we will only update the subset when we need to. Second, we can use it to it to know if our subset is up to date (more on that later).

The next step is to build an Update Subsets view on the module. To do this we:

• Bring the list into the rows and the line items into the columns
• Select only the line items we need for the update to be displayed
• Filter the view to be only on lines where the 'Update Subsets?' line item is set to TRUE. As we can see, there are two updates required for Tunisia and Germany:

The filter applied:

The last step is to build the import job from the view you just created. Another tip is to make sure you have the string 'Subset <list name>' in your import so that it is easy to find the job as it is easy to end up with hundreds of actions in a model. 

Note: When creating actions like this, you should consider concurrency issues that may arise if you have lots of users logged into a system and someone runs an action. See Planual 5.01-03 Keep User actions (in general to a minimum).

Status reporting

We now have our automatic process for updating the subset, but what is the final piece? We want our administrators and users to know when a subset needs to be updated so they don’t have to run the update all the time to be sure they are. We can do this using the 'Update required?' line item we created in the last step, but we need one additional line item: a dummy line item from our Dummy list (which is a list with one member and a total).

A closer look at our Dummy list:

Next we create a new output module where we can report on the status of the subset (is it OK? Are updates required?). This module is a flat module that has no 'Applies To' overall, but our 'Updates required - Country?' line item has some special properties:

1. It has our Dummy list in the 'Applies To' (for this line item only)
2. It has any summation
3. It uses the formula: 'SYS01 - Country'.Update subsets?[ANY: 'SYS01 - Country'.Dummy]

It is shown below:

This lets us take our 'Update Required?' Boolean in the source module into our flat target module without turning on the aggregation (and ruining our view filter) or creating a separate line item just for the status. It is a bit over-engineered in this simple example, but the idea is that this Dummy dimension can be used throughout the model to get around using native summation.

Below is how it appears in our subset status module. You can see that subsets from other lists are also added:

A nice touch is to add some conditional formatting here to indicate when something needs attention and to publish the required process nearby. You can even add a message here letting the user know exactly what needs to be done.

And when the subsets are up to date:

Conclusions and considerations

Here we have a simple, sustainable, and scalable way of managing your subsets. How does this compare to how you manage them in your Center of Excellence? Is there anything here you disagree with? Let me know in the comments.

Additional notes:

• These rules should only apply to production lists. For structural lists, they are not relevant (as these can’t change in a deployed model). If you need a bit of a reminder on how they are different, head over to this article Production Lists - Overview.
• The example used is a standard list. If you are using a numbered list, be sure to add the code in your update view.
• Be careful about unintentionally deleting subset members (particularly if users are entering data against them as in this example). If the subset updates to remove a member, any data stored against that member will be lost.

andrewtye

Nice summary @whitby!

E2EJonathan

I have all subsets in my CoE updated through regular scheduled processes that occur a few times a week.  On the scheduled datahub to spoke model process there are actions included similar to yours here.  CloudWorks or other integration tools work great for this.  When we have models that create new items we can use forms in the UX to maintain subsets.  For anything more dynamic, I prefer to filter things rather than use subsets, as I don't like the potential data loss for moving things between subsets.