Currently, one very useful action that is still only accessible in the classic UX is "Copy Branch".
I can not be the only one who wishes this incredibly useful action could be run by a user in the NUX.
Please add it!
Agree ! This one is absolutely necessary for easily working with what-if scenarios.
Agreed this action is required
Until the functionality is added to the product, this may work for you as a workaround.
https://community.anaplan.com/t5/Best-Practices/Copy-Branch-Workaround-for-the-User-Experience/ta-p/98143
Thanks @paul_gibson.
Sadly however, where non-native versions have been used (which I personally strongly recommend), the copy branch functionality is really the only way to copy a version. The workaround you've suggested can be effective in small doses but is far too cumbersome to copy a whole model.
Has there been any indication from the product team as to when we can expect the functionality in the UX? Until it is users will still have to engage with the classic UX...
@tscott In the case of a non-native version copy, could you not have a process to copy the data from one version to another, where you select the source and target? Or have you got lots of branches under main versions and you want to copy them all at once?
I have built a number of models previously, where I keep lots of non-native versions / scenario data, in a fairly flat module and then pull it back as required for reporting. I'm happy to take a look at your issue, if I can be of help.
I haven't seen a timing for when product will develop the functionality, hence the alternative thinking approach.
@paul_gibson Ah that's a shame about the product development timetable. Hopefully if this thread gets some more traction it might be pushed forward!
The problem with the process approach is when you have a large model with many user input requirements it is very burdensome to have to create import actions (and error-prone) for every data/ input module which is dimensioned by version. It could even become a problem if other developers are not aware that this approach has been taken since it would be easy to add a line item and not update the relevant copy action.
I agree the workaround is effective for smaller models where the same functionality can be achieved with a process however to be 100% confident in a copy with a large model I personally would feel more confident with copy branch.
i do support this idea
Adding my support for this idea. Key piece of functionality in Anaplan
Sorry everyone - I'm a little late getting around to updating this post but I'm switching this to "on roadmap" as something we'll be tackling this year.
If anyone wants to chat through how you use Copy Branch then I'd love to hear from you (and maybe get a quick demo of your current scenario).
Hi, is there any progress on this, is it still on roadmap and should it be delivered soon ?
thanks
Hi @jb.neel - Copy Branch in the UX was released earlier in the Summer - https://product.anaplan.com/june-2023-releases-and-july-sneak-peek-edd35fe1-e7e7-4726-839d-269f9dbac228
Wonderful
Thanks for your reply
remember you can only use copy branch on lists with a parent
https://help.anaplan.com/copy-branch-action-12aca940-6143-4231-bb7d-bc1639b8375e
To maintain efficiency and performance, model builders must periodically remove unused or irrelevant line items. At present, the [Referenced By] column in the blueprint provides visibility into dependencies between line items. However, for line items that are not referenced by other calculations, builders must manually…
When we use "Anaplan Extensions", we can check "Filters used in Pages" now. But we cannot check "Filters used in Saved Views" and "Filters used in Context Selector". We want to have a function that allows us to check "Filters used in Saved Views" and "Filters used in Context Selector" in "Anaplan Extensions".
When we access a model that belongs to a different Tenant that the one we are currently viewing, the Tenant does not switch automatically. Example: Tenant A: Model 1 Tenant B: Model 2 ① We view Model 1 (Tenant A) ② We try to access Model 2 (Tenant B) ⇒ Tenant does not switch automatically
