Help: Saved View with Production List (versions) not pulling through to Prod - ALM

We are creating a saved view in Dev that uses a Production List, and the view is not populating in Prod when we push through. This seems to be an issue that would be common, but I wasn't able to find a community solution.

The saved view has our custom versions list in the columns, the issue is since our custom versions list is a production list that view is not available in Prod...where we can't save views. At this point I would be afraid of changing the lists status as a production list and recreating it in Dev because I am not sure if it will lead to other damaging changes.

I believe "current forecast" was originally in the versions list when it was pushed to prod, before it became a production list, and that is why it shows up in the saved view in Prod.

We have versions dashboards that basically have a selector for version A, version B, and then line items referencing those versions. But we want to have more static presentation dashboards that show the versions in the column versus A, B, etc.

Pictures attached.

Thanks for your help!

SV_pivot_101045.PNG

SV_Prod_Module_101045.PNG

SV_Dev_Module_101045.PNG

Accepted answers

jasonblinn

@jakesachs

I would recommend that you set up some filters (Booleans that can be checked) for the different saved views. This would be dimensionalized by your fake version list and would allow you to check whatever you wanted to be displayed in the saved view. Then you apply that filter to your saved view, and each time that you want to update the versions in your saved view, you just check different boxes in the filter module.

The reason in which your current method is not working is that because the list is production, the list items are not the same in DEV and PROD. Behind the scenes, there is an index # associated with the list members. The current version shows up in both because it was likely created before the copy of the model was taken to create DEV. So that Index # is the same in both models. 2021 Annual Plan was likely created after, and therefore in DEV it would have a different Index # than PROD despite them being called the same things.

To confirm one of your thoughts, you do NOT want to uncheck that list as production if there are inputs on it. In my experience, that basically deletes all of the list members in PROD and replaces them with the corresponding ones in DEV, and would wipe all of your data out.

Hope this helps!

Jason

All comments

DaanishSoomar

Hi @jakesachs,

This is an interesting situation. May I ask how the versions list is configured in the Saved View in the DEV model? Are you using a filter on the custom versions list via a boolean? Or the show/hide feature?

Since the list is a production list, the show/hide may not give you the results you are seeking as they are dependent on specific list members.

Are you able to provide more details on what is driving the saved view in DEV? As you know in ALM, structures are pushed through to PROD but not the data.

So ideally your structure is formula driven or logic driven rather than dependent on particular list members.

jasonblinn

@jakesachs

Hope this helps!

Jason

DaanishSoomar

@jasonblinn - great minds think alike 🙂

Glad we had the same thoughts on our responses. Looks like we replied at the same time.

jakesachs

We are using show/hide, and I believe you are correct that current forecast was created before ALM so the index # is matching (I was brought on after this was done, still playing some catch up). Thanks for the advice on not changing it back from being a production list.

In terms of executing the filter....would you have a Filter: Versions module dimensionalized by our custom versions list. Then have a line item for each type of saved view? So for Financial Summary New UX, create a line item in there for that. For any other usage, just add another line item for it?

DaanishSoomar

Hey @jakesachs,

No problem! That sounds like the best approach to me. You can really create as many line items as you want, keep in mind from a PLANS perspective there might be particular custom versions filters you want to reuse across many modules. Maybe you have some logic that can drive the creation of those line items, this is context which you will better know about the nature of the work you are doing. Definitely make use of Booleans for filters! They are the best way to capture filters.

Once you have filters created, and apply them to your preferred modules, then you save your views, you will have filter driven saved views which will carry over to Prod, and the structure should remain intact. Hope this helps!

Quick Links

Can you help?

Unanswered questions

Prevent end users deleting a list item when using Worksheet in UX.
Hi, I have a worksheet for end users to enter new hires into, for which the list item which persist across versions. I am having an issue where the end user can delete a list item using the grid functionality because the Current Version value is blank, but I want to prevent them deleting them (as data will be lost from…
Introducing Anaplan API Python SDK
Hey everyone, I wanted to share the Anaplan Python SDK with you. It's a Python Library that wraps all Anaplan APIs and makes it easier to interact with Anaplan programmatically. It is mostly designed with Data Integration Scenarios in mind, but it does support all APIs including ALM, SCIM, Audit, and Cloud Works. Please…
Cloudworks Big Query Integration Fail
Hello, I am receiving an 'Anaplan Upload Failed' Status Description when testing my integration with a Big Query dataset. The integration imports data from BQ to our Anaplan model. No other details given in the error log. I suspect that Cloudworks is not even picking up the file but am not sure what we did wrong on the set…