Upcoming UX ALM and forms functionality

Community Boss

Throughout October, we'll be introducing features to enable a single page to support application lifecycle workflows without the need for separate development and production apps. Specifically, where you have access to the models, you can:

  • Choose between different source models associated with a page.
  • Associate multiple models with a page so you can switch the source model of a page as part of an application lifecycle; for example, Dev, Prod 1, Prod 2, etc.
  • Make draft page changes against a development model and save before publishing to the production model or models.

image2020-9-22_12-33-58.pngimage2020-9-22_12-33-43.png

Forms updates

During the week of October 12, we'll also be making updates to how forms work in the UX. Currently, forms are associated with models and the same instance of the form can be reused/shared many times across different pages built on top of the same model. New updates include:

  • Forms will be associated with a single page, meaning it will no longer be possible to share and reuse forms across multiple pages.
  • Existing forms on pages will become standalone, and they will become unsynced from other forms. Any form changes will need to be made to each form instance on every page.

image2020-9-22_12-34-35.png

14 Comments
Master Anaplanner/Community Boss

@Rebecca - why the change in form management? doesn't this sort of go against the reusable nature of different board/sheet elements?

Master Anaplanner/Community Boss

Should also say that's really great about the ALM capability - will definitely make things a lot more simpler when developing out improvements, etc!

New Contributor

Thanks for great news, cant wait! really happy about: Associate multiple source models with a page 🙂

Frequent Contributor

Hi Rebecca,

 

regarding Pages and the multi source models to "replace" ALM, can you clarify how it will work in the follow case:

- a Published Page ABC which is connected to the production model/data

- the Page ABC needs to be changed and should go thu the development/test model/data

 

Will it be possible to have a Page ABC in multiple versions, Draft/Save/Published, and have each version a different source model? If you republish the changes/changed Page ABC and changed the source model, will it "overwrite" the existing one?

 

I am trying to understand what the user/admin experience will be.

 

Kind regards,

Johan

Occasional Contributor

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

Frequent Contributor

Hi Chris,

 

Thank you for the clarification. So there will already be an "integration" with our ALM solution. Great, goods news! It will help our customers which rely heavily on ALM to move forward with UX implementation.

 

Kind regards,

Johan

Occasional Contributor

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

Master Anaplanner/Community Boss

Thanks @ChrisM for clarifications.

 

When I first read about the multi-model on a page, I thought you could have in the same page, some cards connected to a model and some to another model. :). 

 

So, the entire process to change an existing published in PROD page can have these steps:

1. Modify/change structures or formulas in DEV model

2. Create a draft of the page connected to DEV model and use the draft-page and modify it using the new modifications made in DEV in point 1.

3. Wait that the structural modifications made in DEV are pushed into PROD using the ALM 

4.  Go back in the page app an publish the draft modifications made connected to the DEV in order to use the PROD connection. From that moment the PROD page will use with the latest modifications, connected to PROD model. 

 

Is it correct? 

 

thanks

Alex

 

Occasional Contributor

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

Occasional Contributor

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

Occasional Contributor

Hi all - thanks for the update and exciting about ALM, albeit there will be some extra work to use forms. Luckily they are quick to create (even in what we call the “secret menu” on boards for Configure Actions).

 

I’m wondering - will we be able to turn off the Model selector for end users that technically have access to multiple models? We often try to reduce as much Page and Context Selector  clutter as we can, and can imagine a situation where an end user has access to Dev and Prod but we don’t want them seeing that drop down menu on the Page. 

 

Thanks for the great responses and sharing this with community!

 

George

Occasional Contributor

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

New Contributor

Thanks @alexpavel for your clarifying questions, I came to the same initial conclusion that you did. 

And thanks  @ChrisM for confirming what Alex laid out!

Master Anaplanner/Community Boss

@ChrisM - ah that all makes sense now! thanks for the clarity.

Latest Articles
Bar Chart Series Order
Feature Updates
Monday
by VickiA
SS SAML Migration
Feature Updates
2 weeks ago
by VickiA
a month ago
by VickiA
Map Charts
Feature Updates
10-06-2020
by VickiA
Dashboard Import Tool
Feature Updates
10-01-2020
by VickiA