Below are the steps to add any custom entity or OOB entity in New UCI App Area,
- 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
The post Migration from Legacy Webclient to UCI – Adding Custom entity in Model Driven App ( Legacy Sitemap ) – Entity not showing in New UCI – App Design appeared first on Microsoft Dynamics 365 Blog.
]]>We knew that it's because of the responsiveness of the form and that is a good thing it's just they need to understand it better and we have to test it better
Then another was Composite Field which is split into UCI which we for sure understand to make UI more responsive, it was required but convincing system user its been tricky
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
The post Migration from Legacy Webclient to UCI – Responsive Design need Testing – Form Layout Issue – Composite Field issue appeared first on Microsoft Dynamics 365 Blog.
]]>While Initial Pre UAT and Validation of New UCI Transition, We received a lot of issues raised by System users that Layout of form is irregular and they are having a hard time coping with it,
We knew that it's because of the responsiveness of the form and that is a good thing it's just they need to understand it better and we have to test it better
Then another was Composite Field which is split into UCI which we for sure understand to make UI more responsive, it was required but convincing system user its been tricky
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
Then we have 1 more thing which we already informed system user about "composite field", i.e address field splits up
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
The post Migration from Legacy Webclient to UCI – Responsive Design need Testing – Form Layout Issue – Composite Field issue appeared first on Microsoft Dynamics 365 Blog.
]]>Even We know Microsoft announced December as transition date, It is good to check if there is any early Transition Scheduled and Approved on : https://runone.powerappsportals.com
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
The post Migration from Legacy Webclient to UCI – Reschedule Auto Transition date for New UCI appeared first on Microsoft Dynamics 365 Blog.
]]>The post Migration from Legacy Webclient to UCI – The record URL denoted by Record URL (Dynamic) in CRM still points to the legacy web client appeared first on Microsoft Dynamics 365 Blog.
]]>As we Discussed on post how to start UCI Transition validation and keep working on legacy WebClient that workflow with email template and mapped Record URL will need to be validated as those will be pointing to the legacy app
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
The post Migration from Legacy Webclient to UCI – The record URL denoted by Record URL (Dynamic) in CRM still points to the legacy web client appeared first on Microsoft Dynamics 365 Blog.
]]>From PowerPlateform admin center: https://admin.powerplatform.microsoft.com
The post Migration from Legacy Webclient to UCI – Enabling New UCI Unified Client interface for CRM Envirnment appeared first on Microsoft Dynamics 365 Blog.
]]>STEP 3: After Shifting Date of automatic transition from 1st of October to End of December , but still early transition is better.
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,
- From PowerPlateform admin center: https://admin.powerplatform.microsoft.com/
CHECK1 Enable UCI Unified Client Interface from Power Plateform admin Center
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
The post Migration from Legacy Webclient to UCI – Enabling New UCI Unified Client interface for CRM Envirnment appeared first on Microsoft Dynamics 365 Blog.
]]>Migration from Legacy Web client to UCI,
As we Microsoft announced by 10th of January legacy WebClient interface will be forcefully transitioned to UCI. Businesses were informed please start the transition process asap especially for live Environment which is undergoing some fixes and CR in support and should be considered as a mini-project.
Transition to new UCI might be taken lightly by some clients, but this needs to be addressed asap as although moreover, Mostly client-side customization will be affected by this transition and not everything will be deprecated in terms of js, workflow, etc.
But still, if we are in production and supporting fixes and changes, it recommended to slowly start the transition with validation and doing fixes with new UCI compatibility, as recently we went to start doing it for our client and there we realize it not that easy and smooth as it sounds although Microsoft did a fantastic job in slowly making everything new UCI compatible.
I am sharing some processes we followed for our client which were on legacy WebClient and support fixes + CR was under process. so the challenge was to work on support fixes Development, UAT testing, and Deployment to Production, and simultaneously all these fixes should be New UCI compatible and there were New UCI validation and customization happening in parallel.
- NOTE: I AM NOT SAYING THIS IS THE BEST PRACTICE TO FOLLOW JUST SHARING WHAT WE DID FOR SUCCESSFUL UCI TRANSITION AS PER CLIENT SUPPORT DEMAND AND BUSINESS,
Also, these steps will double up the effort of existing support fixes and New UCI Validation
We will divide our post 5 below:
-
Identify the most critical components and the commonly shared component (which almost no effect)
-
Setup Development environment for UCI upgrade and keeping in mind we also have to support fixes and CR to legacy WebClient
-
how to start UCI Transition validation and keep working on legacy WebClient with fixes and CR without overwriting each other changes/ customization
-
Deployment to QA and Production ( for both New UCI and Support fixes/CR)
STEP 1: identify the most critical components and the shared component (almost no effect) ,
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
COMPONENT WITH ALMOST NO IMPACT / LEGACY WEB CLIENT CUSTOMIZATION STRATEGY
1. ENTITY
2. FIELDS
3. VIEW – Search result can vary and need to validate
4. QUICK CREATE FORM – need to be validated
5. RIBBON – There might be new buttons available which system user don’t want
6. BUSINESS RULE – ENTITY SCOPE – if the scope of Old Bussiness Rule is an entity then there is very less chance of an error, but scope with forms need to be reviewed and validated
7. WORKFLOW – As currently workflows are not going away we decided to keep the workflow as it is and will convert them to power automate once UCI upgrade is done. there would be a common issue with content referring to Org URL or record URL which where custom made, those need to be reviewed
8. PLUGIN – if the way using entity form is changed there right be 1 or 2 plugins which depend on js or another web resource/action and it best to check that customization.
9. POWER AUTOMATE FLOW – all-new requirement related to the workflow will be done using power automate
10 SYSTEM SETTINGS – There are some new features with can be managed using system setting and our old customization are of no use, better to update our system with this transition
11. SECURITY ROLE
12. FIELD SECURITY
13. SOLUTION – For legacy WebClient we can maintain solution sprint wise and keep UCI component in different Solution and deployment strategy should be different.
14. REPORT- We didn’t find any issue regarding reports
CRITICAL COMPONENT / NEW UCI CUSTOMIZATION STRATEGY
1. NEW FORM – For critical entities with lots of web resources and flagged component, we decided to create a new form for UCI changes and keeping old form for legacy fixes and customization (we will be disabling legacy UI form once ready for a full upgrade)
2. QUICK CREATE FORM – This doesn’t apply to everyone but if required we can consider creating new quick create form for new UCI
3. NEW WEB RESOURCE – this is the most critical component and we will see in below Steps, how to work on start with Validation on web resource example Javascript
4. BUSINESS RULE – FORM SCOPE – We need to test Old business rule under form scope
5. SYSTEM SETTINGS – there are some common system setting differences related to Formates e.tc which we can cover in below steps
6. WORKFLOW – There could be a common issue with content referring to Org URL or record URL which where custom made, those need to be reviewed
7. PLUGIN – most probably there would be no issue with this component, but as mentioned before if the way using entity form is changed there right be 1 or 2 plugins which depend on js or another web resource/action and it best to check that customization.
8. SOLUTION – UCI UPGRADE PROJECT/sprint wise New UCI changes, keeping New UCI changes and Legacy WebClient customization if the different solution, as we will be deploying legacy customization to production but NEW UCI changes will be deployed to production at once. and we will know in the below steps who to prevent ourselves from the conflict in changes as both legacy WebClient APP and UCI APP in the same environment.
STEP 2: Setup Development environment for UCI upgrade and keeping in mind we also have to support fixes and CR to legacy WebClient
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.
- 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.
- 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.
Check 1. Create a New Solution with Legacy WebSclit Site map/ Model Driven app, which will be used for the creation of new UCI model-driven app
- 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
Check 2. Create a new Model-Driven App for new UCI in same Dev Environment
- 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.
Click Here for Full PostSTEP 3: how to start UCI Transition validation and keep working on legacy WebClient with fixes and CR without overwriting each other changes/ customization
So the most common issue will over following the above structure is
- 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
- 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
Click Here for Full Post
The post Migration from Legacy Webclient to UCI – Unified client interface – Step by Step move from Legacy WebClient to Unified Client Interface UCI appeared first on Microsoft Dynamics 365 Blog.
]]>