Form Classis UI to Freedom UI Transition

Hi, 

Did the switch recently for our sales team: 

- check that all business rules that you use are usable in Freedom UI (eg: you cannot use business rules based on roles in freedom UI)

- Plan for editing both minipages and normal pages

• - some functionalities still do not work in Freedom UI (eg: activities not automatically linking to your opp and account, will be there in 8.1.4, but could be a blocker) or if deduplication is important, make sure you set it up: https://marketplace.creatio.com/app/deduplication-freedom-ui-enhancements 
• 
  - Do not understimate the time to make the UX look good, the advantage of being a better page editor means you need to be careful in giving a UX direction 😉
  
  - User training is important
  
  - before pushing to prod: test, test,test because there are sometimes somes unexpected bugs which the teams are working actively on fixing
•  
• - carefull on the package management with autopackage generation in the latest version of Creatio
  
  Advantages:
  
   1- you can answer to more of your client's requests in depth without needing custom code (doesn't mean at some point you might not need some, but later in more complex scenarios)
  
  2 - all new functionalities are provided for Freedom UI only (including future AI Copilot)
  
  3- UX makes reading data clearer if you use the right colors
•  
• 4- no more limit in functionalities depending on page type
•  
• 5- object level business rules (rather than just page business rules), very useful
  
  Disadvantage: 
  
  Performance is not yet on par of what classic UI and classic shell were able to provide, so you'll quickly have your users complaining that it's a bit slower. But it's getting there, version 8.1.3 shows a good bump in performance improvement. 

One of the best approaches to converting a classic system to Freedom is to make use of the "Object-specific form page interface in the Freedom and Classic UI shell" lookup. This allows you to develop the Freedom UI equivalent while still allowing users to remain on the classic versions of the screens. Once the Freedom UI equivalent of the screens are complete and ready, you just need to switch the default for that entity in the lookup and users will begin seeing the Freedom UI version (along with swapping out the exposed section in the workplace to switch from the classic section to the Freedom section)

I've typically taken this approach: 

1. Switch users to Freedom UI shell, but remain on classic screens
2. Convert a section to Freedom UI, once complete switch in lookup and workplace
3. Once users are using the new section work on switching any related detail edit pages to Freedom screens if applicable
4. Repeat for next section(s)

A few random thoughts to add: 

• As Damien mentioned, it's a bit slower, but has been getting faster with each version. 
• There's a few things you might run into that isn't yet possible with Freedom UI. However, the ease at creating complex UIs is a nice trade off. You'll spend far less time doing tedious things for the UI such as adding buttons, labels, custom filters, etc and just focus on the actual business requirements. It really does make a lot of things "no code" that used to require code to accomplish.
• The auto-refresh of records that have been modified on the back end or in processes is one of the best things in Freedom UI. Make sure you enable this - then you can rethink how data gets modified and do more via no code in processes rather than in the page code. 
• Definitely get rid of the classic UI thinking. You can do so much more with screens, adding metrics/charts and other elements to lists and screens to make them far more visual & useful for users
• It can be frustrating that new Freedom pages don't always go in the package you want. You can control this by adding packageUId in the URL of the page designer or disable the "smart" package feature so it just uses the current package system setting. 
• To get the UI how you'd like don't forget you can put containers inside of containers. A layout element can have nested layout elements to split up cells/controls. 
• For the most part, I'm always disabling editable lists so they aren't editable. You lose too much control over things in an editable list for now. Hopefully soon we'll be able to have events, rules, validation, etc for editable lists, but that isn't there now.
• The lack of Freedom UI specific documentation is frustrating. Going beyond "no code" seems to be pushed to the side and it's not uncommon that code will break between versions. It's completely aggravating. Luckily, there's a huge amount of things that used to require code that now can be done with a no code approach, however, it doesn't cover everything and once you need to go beyond no code it can get frustrating at times - especially with such little documentation (or none) on the topics. I do have a lot of articles on things I've discovered with coding for Freedom UI screens here. 

Ryan

Damien Collot,

Perfect. Thank you for the detialed notes. All points are noted

Ryan Farley,

Perfect. Thank you for the detialed notes. All points are noted