About ChrisM

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