About ChrisM

We are investigating a mechanism to more formally define the different lifecycle phases of an app and how different models can be associated with those phases so that users do not have to switch between models across different phases at the individual page level. Until then, the current behaviour should remember the last selected model for a particular page across different user sessions.  Thanks ... View more

We have a roadmap item to set the restrict access configurations for all pages in an app at once (as per https://community.anaplan.com/t5/Idea-Exchange/New-UX-restrict-access-to-multiple-pages-at-once/idi-p/55618).   I assume this request is more around setting the configuration once for the app and all pages inherit those permissions, which is not on the roadmap at this point in time. ... View more

I am pleased to say that this is on the roadmap and should be available soon. ... View more

I am pleased to say that we have app-level page access control functionality on the roadmap. This will make it quicker and easier to view and manage page access restrictions for all pages in an app at the same time. ... View more

We have now launched this capability for Anaplan's UX! Here is a best practices link for more information: https://community.anaplan.com/t5/Best-Practices/Application-Lifecycle-Management-for-the-User-Experience/tac-p/74769 Thanks! ... View more

Hi @gheiler , Thanks for highlighting that use case. The first increment probably won't have that level of control; so if a user has access to the page and multiple models associated with the page, they would see all of those models in the list. That said, it will still be possible to restrict access using model roles, so if the model and page builder's role, end-user's dev role, and end-user's prod role are all different, it would be possible to turn off page access for the end-user dev role, which would mean they could only see the page and models for which they had the end-user prod role. Please feel free to send me a private message so that we can discuss this scenario some more if the above wouldn't work. Thanks, Chris Marriott ... View more

Hi @andrewtye , Currently forms are associated with individual models rather than the page. In order to provide capability to change a page source model depending on its application lifecycle phase, forms must be associated with the page instead of a specific model. When added to a page, the form will be able to support all models associated with the page. For example, in a split production model scenario (ie. Dev > Prod 1 and Dev > Prod 2), currently 3 forms would be required across 3 separate Pages (1 for each model on each page), in the future a single page will be able to support all 3 models (Dev, Prod 1, and Prod 2), and the single form on the page will work against all 3 models. In this scenario the form is still being reused, but across multiple models with the same structure, as opposed to the same model across multiple pages. Thanks Chris Marriott ... View more

Hi @alexpavel , That process is correct, yes! Sorry if there was confusion over a page supporting cards from different models - I can confirm that is not going to be possible as part of this capability. Thanks, Chris Marriott ... View more

Hi @johan_vangerwen , Initially the Model Sync ALM process will be separate to the UX ALM publish process. This is also something we want to integrate in the future. Thanks, Chris Marriott ... View more

Hi @johan_vangerwen , With this upcoming change, a Page will be connected to both the Prod and Dev models at the same time. Draft changes to the page could be made based on objects and structures in the Dev model. These changes can then be saved and published once the ALM Model sync process has been completed from the Dev model to the Prod model (ie. when the Prod model has the same structures as Dev). In the future we want to make it possible to publish different versions of the page against different associated models as you suggest, but initially the publish action will publish the current draft version to all associated models at once. It will be possible to integrate a Test model into the flow via the duplicate App capabilities - I will be writing a blog about that when we launch these capabilities. Thanks, Chris Marriott ... View more

Hi @Misbah,  I believe the current permissions behaviour is similar to the model synchronisation capability of ALM, ie. the user performing the model synchronisation needs to be a workspace administrator of both the source and target models. Maybe you could send me a message and we could start a conversation about the implications of that current requirement? Thanks, Chris ... View more

Hello, I am pleased to say that this item is on the roadmap and we are hoping to deliver it soon. Thanks ... View more

Hi @alexpavel , Thanks for your input. I am working on this project with @sprender and hopefully I can give you some reassurance. 1 and 2 - We have plans for a history/version log in Phase 2 - we’ll be sure to incorporate your feedback. We also have plans to highlight to page builders where draft versions exist so changes can more easily be tracked down. 3 and 4 - Phase 2 includes the concept of App Modes which will introduce a more formal process around draft and published versions of pages - this will eliminate the need to delete prod apps to update them with a new version. I hope this helps Thanks, Chris ... View more