Export list updates

This is definitely not the most elegant solution, I would go with model history proposal, that will give you exactly what you need (you can also save it as an export to your dashboard).

But if you wanna prospect further my recommendation, here what I was referring to: beware, you will need to export two files & you can only trace the last change on a list item.

You can then create exception modules, down below shows re-naming and deleted items. You can an create additional module to apply to original list that will show you new items.

- you need to create filters and save the view; then save export definition

- ultimately you need to setup a recurrent process to sync again the two files: remove fake list items, copy again from original, copy list properties.

For a not so complex process (where users won't do multiple changes to same line item) you could potentially use the approach, otherwise it's not a reliable solution.

All comments

KirillKuznetsov

Anyway to be able to see changes you need some king of "before/after" comparison somewhere.
You can setup an API process to extract all the info from all of the lists (i.e. via saved view of attribute modules). And when run the API job - you compare this export with the previous one to see what has changed. Make it automated.
Or you can build a process in the model. The same idea. All the info collected in some storage for later to be able to compare it with new edits.

@ShubhamCh What you want to achieve it's a bit more complex if you want it to be working for re-naming and deletion of list items. But should be doable.

1. Create a second identical list that includes all list items with identical code names/numbering.

2. Create a property "original item" in second list (list formatted) and create an import action from original list to "copy list" and map by code.

3. create two modules where you will apply each of the two lists: (one will help you see renamed and deleted) and the other will help you see added list items.

Module 1: (applies to your copy/fake list)

Create line items: line item name /code / original line item name / original line item code - you can then compare the names of the two lists - where false, that means you've changed the name in your original list. Where blank (original name & original code) - it means list item doesn't exist anymore.

Module 2 - do the same thing - only this time blanks represent the the line items that were added in the list. Here you'll probably need similar approach to step 2(only the other way round).

4. Create exceptions views that you can apply to a dashboard or create export actions to only download the changes.

This will only work if you have clear timeframes for when you will perform the checks. At some point you need to clear and import everything from original to copy/fake list - at the beginning of each day/week, someone need to run the process so that the two are in sync.

@ShubhamCh

I go around to solve this problem in either of two ways:

1. Delta Capturing:

Every time I create/update an item in a list, I create a boolean true as a token of change in a record.

I export only the records which have this boolean as true.

After I export the records, I run an action that turns all true booleans to false, this makes the system ready to take up future changes as Delta.

2. Timestamping

I can keep a recurring job in my system that wakes up every 5 minutes and updates Server time into one of the line items. [Anaplan connect or any ipaas tool]

Every time a new record/update is created, I include capturing the timestamp to the process.

My export can easily identify the new changes by comparing the current time to the timestamp noted for list item change by doing a simple comparison in time values.

Thanks

Aditya Shubham

Hi @Alexandru.Rosca

I didn't get the structure of the two modules. "Create line items: line item name /code / original line item name / original line item code", Please explain this line.

One more question, how I will compare the names of from the original list with fake/copy list in a module which has copy/fake list as a dimension only.

How do you propose to setup the export module to combine all this delete, renamed and new member info from every list in one file?

- Shubham

https://help.anaplan.com/6d96706b-61cc-4b15-84a6-00c9f8a15cc2-Changes-visible-in-model-history

Hi Aditya Shubham,

I like Delta Capturing but in my case the users will be creating new members in lists from a page. So I want that boolean to turn true by itself and I also want all rename members from all list in one module with their parent list. So I can export it only in one file. Do you have any ideas for that?
Thanks!
- Shubham

ryan_kohn

Is there any reason you can't use the Model History to review the item changes? The information you're looking for is exposed in the model history.

This is definitely not the most elegant solution, I would go with model history proposal, that will give you exactly what you need (you can also save it as an export to your dashboard).

But if you wanna prospect further my recommendation, here what I was referring to: beware, you will need to export two files & you can only trace the last change on a list item.

You can then create exception modules, down below shows re-naming and deleted items. You can an create additional module to apply to original list that will show you new items.

- you need to create filters and save the view; then save export definition

- ultimately you need to setup a recurrent process to sync again the two files: remove fake list items, copy again from original, copy list properties.

For a not so complex process (where users won't do multiple changes to same line item) you could potentially use the approach, otherwise it's not a reliable solution.

Hi Ryan,
I think History won't work in my case because I want to export updates related to list only but in history we get all the information about the model for the selected time period. Is there a way to filter out history for list updates only?

ryan_kohn

You cannot export only list updates, but you could still filter the exported History after you export it using the Module/List column.

Thanks @Alexandru.Rosca!

I found your idea feasible for my scenario. It is not the exact answer but I used it to solve my problem.

Accepting your reply as the solution. Kudos to you!

I think Frequent Model History Query may not be good if the model is used by a lot of users, If the query takes too much time to process, the model will not be accessible to users for that particular window. Let me know if I'm wrong.

1. Why would you use a list Item when we just need a boolean which tells us if the export is required or not?
2. Why would you use list properties to keep this data when any data can be easily kept in a system module?
Let me know if I'm missing anything

You can do the opposite boolean in this case, after you have exported latest records you switch all booleans on. Net time a new record is created it will only have false booleans as new records, export records with false boolean and run an action to make everything true.

ryan_kohn

You didn't outline in your original post the reason you need to do this sort of comparison.

Why do you need to export the comparisons? e.g. is the data relevant to the planning process and need to be kept and exposed within Anaplan
Which downstream processes do the outputs drive? How immediate are the results required for those processes? e.g. is this a monthly audit report, or are you trying to proprogate the changes in other systems, or something else entirely?
Are these updates to core model data that should be updated within a Data Hub? Doing this in a Data Hub will reduce the performance burden on end users if you need to run exports from the model, as end users would not have access to the Data Hub.

Without a better understanding of the requirements, it is difficult to recommend the right approach. The above are some things to keep in mind.

@ashubham I don't see how you could keep track of the deleted items without keeping a copy of the original list. Yes, you will be using a Boolean to tell you if the export is required, but you need to compare both ways. Agree, List properties can be kept in a sys module, it's my recommendation also, but for this exercise it was faster for me to showcase the example.