• Open we can Go to Customization and select Model Driven App (It can Be sales hub, or custom Model-Driven app created) where you want to add this Entity or Create a solution add your Model-Driven app and same Solution you can move to UAT / Test Or Production

  

• Here we have 2 option Either we can edit Sitemap using sitemap designer to add entity in Sitemap
  

  Click Here to check how to Edit Site Map

• and not to forget to check, the entity is added in App Designer

So receiving from layout issue by system user will be common while transitioning to New UCI especially if we have lots of information on our old legacy form to make it more interactive for the system users

• Above image, we can see if we open New UCI of our dev in Ipad both have different section view on the screen (note these are not divided into tabs, we are taking example of the section itself, if we see new UCI of above record it will show us 2 columns instead)

• So the Unified Client interface uses responsive web design to provide an optimal viewing and interaction experience for any screen size, device, or orientation.
• But it better to test it from development and validation perspective before handing it over for UAT and we can do the Responsive testing in our web browser itself, chrome, firefox, etc

• GO to the page which needs to be validated -> Press F12 to enter the dev tool and once inside devtool , you can see device button on very left top corner (chrome)

• There we can choose between different Devices or resolution to see how the page is rendered

We fully understand why removing composite is done and frankly don’t like composite field much,

so we informed system user that this is going to be permanent for now and the reason,that to make our new UCI more responsive this might be essential step like if we want to access the environment from a smaller screen, pop from the composite field would not fit in a responsive manner and it was this easy to explain to them until we ended up creating a field to populate split value into a read-only field

1 thing to remember there might be early transition mentioned for your environment but until it is approved nothing will happen unless we reach forced scheduled date

• Navigating to URL: https://runone.powerappsportals.com

• Navigating to Environment, We will see all our organization with scheduled transition date and status

• Clicking on Friendly name and selecting Reschedule Option on top, Don’t approve early until ready

and once ready with the Validation and customization, go ahead and Approve – Check the post where we have to share our experience on step by step transition process 

So We might be having many Workflow and Email from Pluginif any which would be mapping Record URL in body of the email or any other notification / Location, \

• Ideally, we want o to include Appid so, whoever clicks on record URL , they should jump on New UCI instead on the Legacy app or don’t want it to break at least

• Alpha bold has written a nice blog on how to resolve it, Please follow the same. thanks

Navigating to UCI from Record URL (Dynamic): A Custom Code Solution

If We did our Dev New UCI Validation and transition early so we can be sure there is no blocker and we don’t need to roll back as we were already live,

1. From PowerPlateform admin center: https://admin.powerplatform.microsoft.com/

We can navigate to the Admin center from make.powerapps.com or directly Navigate to  : https://admin.powerplatform.microsoft.com/

• Now select the Environment which needs to be transitioned to new UCI -> Click on Setting

• Setting – > Behaviour

• Enable by Checking Use Unified Interface Only

So the most common issue will over following the above structure is

1. when we will work on Legacy WebClient App for Support fixes and CR, it might overwrite the changes done for UCI Transition and the changes Done for UCI transition may overwrite changes done for Legacy Web client App
2. The new fixes being done will keep on adding up even if those are not compatible with NEw UCI

I have put up some process point we adapted while working on the transition

• For Validation on UCI and as per Business; we chose a strategy to go Entity wise to Validate components i.e web resource, Ui, etc for each entity starting with Account
  As our Account entity had lots of Web resource and not to miss most of the web resource were written 5-6 year back in on-premise org,
  So we Created New Form, coping Legacy Form for validation and changes- If we find any issue in an webresource , we do the changes in such a way that that customization is compatible for both Legacy UI and New UCI and maintain component in Bothe solution, Bux fix on Legacy WebClient and Solution on UCI upgrade project ( We were managing all these in User stories, Tasks, and Statuses which we used in final Production tradition )- If somehow Web resource customization can not be compatible for both New UI and Old WebClient (unsupported web resource I am assuming). We will create a new web resource which will be attached in new form and making sure it’s not impacting legacy WebClient app component or flow,
  then we will maintain a ticket in VSTS stating in final production transition we need to disable Web resource in Legacy WebClient, though We already created New form and new web resource and while production transition we have working webresource in New UCI form.

• 2nd Scenario can be as following, We received a bug/issue and this fix needs a change in  Javascript  (Web resource 1), and in parallel, our Validation and customization going on-> We will fix the issue in such a way customization is compatible for both Legacy webClient and New UCI and this way new customization will not be any hindrance in Production transition-> 1 thing to remember This will result in Double effort and Slow fix delivery and Client should be notified about these in advance.

Below Table contain some more info on the process we followed and again mentioning these are not Best Practice , was followed to take care business Support Demand and issue logs, as recently we were moved from On premise to Cloud with very old codes.

REGULAR APP/ OLD UI			NEW UCI
–  We will keep supporting and using existing UI on regular main.aspx page			– Separate App has been created using old UI customization
– For new issue or change request on OLD UI , Customization done should be compatible with OLD UI and NEW UCI			– we will start our validation, entitiy wise on new APP
– Compatible with OLD UI and New UCI means, Functionality should be tested in both OLD UI and New UCI. For example if we need to add filter on a lookup , testing will be done in both apps.			– Suggestion : New Prefix can be used to identify new changes “atcc_customization”
– if customization/development done can not be compatible with both OLD UI and NEW UCI at same time, 2 Seperate customizations will be done 1 for OLD UI and 1 for new UCI. We will Create a User Story Tagged as UPGRADE CHECKLIST , where we will maintain this customization was done separately for OLD UI and need to be removed/reviewed on Upgrade of QA.			– Will Create new “FORM” for each entity starting with Account and start our validation
– All new Issue fixes or Change Done compatible with OLD UI and NEW UCI  need to be kept in Sprint Solution with Postfix (UCI or any suggested)			– While Validation if Issue identified, Customization will be done so it should be compatible for both Old and New UCI, and changes and ticket will be added in Current Sprint (UCI)
			– if Customization/Development is done can not be compatible with both at same time, Separate customization for only UCI will be done where new webresource / component will be created for new form.
– All New Issue Fixes or changes Done which are not compatible with New UCI will be kept in Different solution “SprintName + Postfix (NONUCI)”			-All Customization done for UCI will be added in Solution “UCI UPGRADE PROJECT”

By Identify Component which may or may not effect from the transition doesn’t mean we will skip the component listed in May, not have any effect.

The critical component will be the one which will be tested thoroughly looking into Error and creating a new component for change and functionally to work so it doesn’t affect the legacy app till we are ready for Production Upgrade,  example  –New form for the critical entity  ( our org was recently upgraded from on-premise environment and vendor worked on it left javascript as it is if it’s not giving error, even if the functionality was not working or partially working, So we opted creation on a new form for UCI so there would not be any conflict on legacy web client customization as we frequently fix the issue and deploy to Production)

We will go through more about how we segregated legacy web client customization with  New UCI transition Customization in Setup Development Environment 

Also below list was specific to customer current requirement/business process and might differ from business to business

There was 2 option for us to work with New UCI Transition customization and Validation and keep working on Legacy WebClient for Fixes and CR.

1. Create 2 Dev Environment, 1 for UCI and 2nd will be for Legacy WebClient, but this would have resulted in an unequal environment at the time of production upgrade as there would be some changes in the legacy app and then a few changes in New UCI Dev environment. until we keep on merging them with each customization and that would be almost impossible to achieve especially when we had a large number of fixes and cr each week, this would be ideal for a freeze environment with new fixed or changes, So we adopted the second option.
2. Create a new Model Driven app using legacy WebClient Sitemap and customization: so we will create a new UCI Model-driven app and same time keep Legacy WebClient so dev environment will be with the latest change regarding new UCI and Legacy WebClient

Only thing is to manage to work on customization of New UCI and WebClient without overwritten/damaging each other customization. we will check this in step 3.

• Creating a new solution from make.powerapp.com

• Add Site Map or Model-Driven App in the Solution -> App -> Model Driven App
  Solution -> Others -> SiteMap

• We Export the solution as a backup, but the main use of this solution will be when making Model-Driven app

• Creating a new solution from make.powerapp.com with name UCI UPGRADE PROJECT

• Create a new app and select use  Existing Solution,

• We will select a previously created solution with site map.

We have 2 apps in same DEV ENVIRONMENT, so We can work on new UCI model-driven app for validation and customization and Regular legacy WebClient App for Fixes and CR for Regular support.

So the most common issue will over following the above structure is

1. when we will work on Legacy WebClient App for Support fixes and CR, it might overwrite the changes done for UCI Transition and the changes Done for UCI transition may overwrite changes done for Legacy Web client App
2. The new fixes being done will keep on adding up even if those are not compatible with NEw UCI

I have put up some process point we adapted while working on the transition