Sunday, 30 April 2023

{Do you know} now you can share records with specific people in a email

Hello Everyone,

Today i will show improved UX on sharing records in Model Driven Apps.

Lets gets started.

Suppose you want to share a record you own to specific people in a email link.

Now with Improved UX fron Microsoft, thanks to Microsoft for making easy sharing feature for the users.

So open your model driven app and share the lead with your colleague.


Click on the share button and then click on the Email link icon.


If you want to share with Specific people then click on the "People with existing access"







Then click on the specific people and click apply.







Search for the people you want to share and click send.


Note: the user who is being shared record to will only get read access based on the previleges they have on the table.

Also if you want to revoke access then click on share and "manage access" and remove access.


I hope this helps,
Malla Reddy(@UK365GUY)
#365BlogPostsin365Days

Saturday, 29 April 2023

Implement Healthy Project and Solution ALM

Hello Everyone,

Today i am going to share few point which helps in implementing successful ALM in your organisation.

Lets gets started.

Conflict and merge resolution: 


Suppose multiple developers working on the solution, it is important to have clear idea of who is working on which component. 


So it is important to have an idea of which pieces will be merged and which pieces will be worked bu single developer.



Branching strategy: 

Branching strategy should make sure while working on next version you can service an existing release.









Environment Strategy: 

Each developer should have own developer environment when multiple developers work on same application.



So always make sure the development environment is from latest build. 

Note: only required unmanaged solutions installed and all dependent solutions are installed as managed.



Power Apps component library:

 Components are reusable building blocks for canvas apps so that app
makers can create controls to use inside an app, or across apps using the component library.

I hope this helps.
Malla Reddy(@UK365GUY)
#365BlogPostsin365Days

Friday, 28 April 2023

How to do bulk update records using Power Automate

Hello Everyone,

Today i am going to share my experience on how to update a invoice record where the option set field value needs to be updated in the lookup field on same invoice entity.

Scenario: Requirement to remove the Option set field and before that happens that option set value should be updated in the Lookup field which have same string value. The purpose of it is to do bulk update of all invoice records with business unit lookup value.

Lets gets started.

Login into Power Automate here

First choose manual trigger flow.

Then initialize variable "department" and choose Type as "string".



Then select "List rows" which is for list invoices.

In the table name column choose "Invoices" and in the filter rows paste the "schema name" of the business unit field  not equal to null from the invoice.
 


As the business unit field is already exists in the invoice table, the purpose of this flow is o update the invoices records, copy the values from the department "option set" field value and update in business unit lookup field.


Once that's done, choose the "apply to each" and then "set a variable" with the "department" which we already initalize before and the 


set the value field from the "Expressions" with value: items('Apply_to_each')?['gmr_department@OData.Community.Display.V1.FormattedValue']




Then choose the List rows: List business units 
select the Business units on the table name field, and filter rows by name eq "variables('Department')".




Then choose another "Apply to choose 2", create a update rows - "Update Invoices"



Table name: Invoices  and row ID equal : items('Apply_to_each')?['invoiceid']


and business unit field with  -  items('Apply_to_each_2')?['businessunitid']




Finally save the flow and test it and all the invoices will be updated on business unit field.



I hope this helps.
Malla Reddy(@UK365GUY)
#365BlogPostsin365Days

Thursday, 27 April 2023

{How} to find out Tenant ID in Dynamics 365 CE Apps

Hi Everyone,





Today i am going to show how to find out the tenant id from Azure portal for Dynamics 365 CE Apps.


Lets gets started.






Note: You need to have System Administrator rights to access the azure portal and tenant wide priviliges to see the Tenant ID.




As you can see the below screen shot, the tenant which i have logged in from the azure portal.








Click on Azure Active Directory and click on the properties, check on the above screenshot.







I hope this helps
Malla Reddy(@UK365GUY)
#365Blogpostsin365Days



Wednesday, 26 April 2023

{How} to determine your Organisation ID in Dynamics 365 CE Apps

Hello Everyone,

Today i am going to show how to identify your Organisation ID in Dynamics 365 CE Apps.

Lets gets started.

First login into your Dynamics 365 CE App.

1. www.admin.powerplatform.microsoft.com


2. choose the environment and choose the app.



3. Now click on the Gear icon and select the Advanced Settings.




4. Then select the Settings and Developer Resources





5.Now check the instance reference information and copy Organisation ID and Organisation name.

ID : ORGANISATION ID
Unique name: ORGANISATION NAME




I hope this helps
Malla Reddy(@UK365GUY)
#365Blogpostsin365Days

Tuesday, 25 April 2023

{How} to turn on Copilot for Power Apps

Hello Everyone,

Today i am going to show how to turn on Copilot for your power apps environment.



Lets gets started.



Then select the Canvas Appt you want to enable the copilot.




Click on edit the canvas app. 




Click on settings:


Then click on the Upcoming Features:


 
Enable the "Copilot Component" as you can see from above screen shot.



In your App menu click on the "Insert" then you can see the Copilot(Preview) 




Then you can start experiment with it as it is in preview, there may be changes to the process we followed in future, so don't take it as is. it is just a guide.

I hope this helps
Malla Reddy(@UK365GUY)
#365BlogPostsin365Days

Monday, 24 April 2023

{Know} Merging managed solutions in Power Apps & Dynamics 365 Apps

Hello Everyone,

Today i am going to share my thoughts on Merging solutions from source to target environments.

What is Merge Solution?


Merge Solution in Power Apps is when you make changes to an entity form which is already exists in the target environment, in that case you can merge the solution.


How to avoid form merging?

Its better to create  new form for the entity which is already exists in the target environment and import into the target environment. this way you avoid merging issues.

Note: Forms for custom entitie won't require merging unless you are creating a solution that updates or modifies an existing managed solution that created the custom entities and thier forms.

When a solution is packaged as a managed solution, the form definitions stored in FormXML are compared to the original FormXML and only the differences are included in the managed solution.

So when the managed solution is installed in a new environment, the form customizations differences are merged  with the FormXML for the existing form to create a new form definition.

The new form definition what the end users can see.


When the managed solutions are uninstalled, only those form elements found in that managed solution will be removed.

How the Form Merge Occurs?

Its happens section by section basis.

For example: If you make changes to the section or tab and import the solution then the changes can affect or conceal the elements from the managed layers, including when the managed element is updated. This  behavior occurs because the managed layers are underneath  the unmanaged layer you are introducing with your customization.

If this type of affect you dont want to happen, then create a separate section or new tab, which is different from the managed solution components. For more information Solution layers

Things to remember:

1. If your managed solution that contains forms that use new security roles depend on those roles. you should include these security roles with your managed solution.

2. When you import a solution that includes table forms, the OVERWRITE Customization option, even if selected, does not apply. The form being imported merges with any existing solution layers for the form.




Note: When a managed solution entity contains multiple forms and the environment entity form also contains multiple forms, the new forms aren't appended to the bottom of the list of the available forms. They're interleaved with the original entity forms.





Merge conflicts Identify and resolving:

Have your ever noticed a "CONFLICTS TAB"  on the form when a manage solution is imported into the target enviroment and some of the components are unable to merge, so the system will auto create this "CONFLICT TAB" and place that aren't able to  merge components in it, in order to prevent any data loss.







How to avoid the Merge Conflicts:


1. You import two different solutions that add a components, such as a form tab, that uses the same ordinal value.

2. When you customize components of the form like the section in the source, but same changes or similar customisation the target environment, then you export the customization from the source environment and import it into the target environment.

So if the conflicts tab appears on an imported form, you can move the components displayed somewhere on the form. Once all the components are moved from the conflicts tab, you can delete or hide the conflicts tab.


Merge navigation(SiteMap) customizations:

Suppose you have imported a managed solution, the SiteMap XML is compared with the original SiteMap XML, so if there are any differences between them, then those new changes are included in the managed solution.

changes like changed, moved, added, removed. When a new managed solution is imported only those changes will be seen by the users, as those changes will be reflected in the SiteMap XML.


So if a visible element is added to the sitemap, it appears at the bottom of the sitemap, if you want to position then you must export the SiteMap and edit it to set the precise location. then import as unmanaged solution to position on the SiteMap.


Only one SiteMap customization can be applied between publishing. Any unpublished SiteMap customization will be lost when a new SiteMap definition is imporeted.




Merge Option set Options:

Each new option set option is initialized with an integer value assigned that includes an option value prefix. The option value prefix is a set of five digits prepended to the option value. An option value prefix is generated based on the solution publisher's customization prefix, but can be set to any value. The option value prefix helps differentiate new option set options created in the context of a specific solution publisher and reduces the opportunity for collisions of option values. Using the option value prefix is recommended but not required.

A managed solution usually updates or adds options for option sets that are already in the environment, for example, the Category or Industry option sets for an account. When a managed solution modifies the options available in an option set, all the options defined in the managed solution are available in the environment. When the managed solution is uninstalled, the options in the option set will be returned to their original state


I hope this helps
Malla Reddy(@UK365GUY)
#365Blogpostsin365Days

Sunday, 23 April 2023

{Know} Layering Solutions in Power Apps

Hello Everyone,

Today i am going to share Solution Layers in Power Apps.

Lets gets started.

Unmanaged and Managed Soltions exist at different layers within a Microsoft Dataverse Environment. Solution Layering is at component level.

Two types of layers:

  • Unmanaged Layer: As we know all new solution developments start at unmanaged solution and on and off customizations exist at this layer. All unmanaged solutions share a single unmanaged layer.



                                                                        Component

  • Managed Layer: All imported, managed solutions and all system solution exist at this level. if multiple managed solutions installed, the last one installed is above the managed solution installed previously. if two managed solutions have conflicting definitions, the runtime behavior is either "Last one wins" or a merge logic is implemented.

    Note: If managed solution is uninstalled, the managed solution below it takes effect. if you uninstall all unmanged solutions. The default behavoir defined within the system solution is applied.
At the base of the managed layers level is the system layer. The system layer contains the entities and components that are required for the platform to function.


Managed Solution Layering:

There are layers within a solution for each managed component. depending on whether one or more patches or a pending upgrade to the solution has been imported  can include these layers:

Base : Located at the bottom of the solution layer "stack" is the base layer. this layer includes solution publisher, which identifies the owner of the component and the managed properties associated with it.


Top: is considered as current layer and defines the runtime behavoir of the component. The top layer can be an upgrade or a patch, or if no patches or upgrades have been applied to the solution determines the component runtime behavior.

Layers added from upgrade:

1. Pacthes: If the component  has one or more solution patches imported, they're stacked on top of the base layer, with the most recent patch residing above the previous patch.

2. Pending upgrade: if a staged upgrade(named -Upgrade) is imported, it resides on top of the base and patch(if any) layers.






Note: Using patches isn't recommended. More information click here


Merge behavior: Merge solution when a solution is updated or when multiple solutions are installed that effect the same component. 
Only Model driven apps, forms, site maps are merged, all other components use TOP LEVEL WINS Behavior.





Top wins behavior: All other components use a top wins behavior where the layer that resides at the top determines how the components work at app runtime. A top layer can be introduced by a staged(pending) upgrade.


Top layer introduced by a pending upgrade:

1. The current top(base) layer has the Max length property of Comments text column for the account table using the default setting of 100.





2. A solution upgrade is imported using the stage for upgrade option, which creates a new top layer. The pending upgrade includes the Comments text column for the account table with MAX LENGTH property value chnaged to 150.




So Comments column for account records will allow up to maximum of 150 characters during app run time.


Solution update and upgrade merge behavior are stacked on top of the base solution. These can be merged by selecting Apply upgrade from the Solution area in Power Apps, which flattens the layers and creates a new base solution.



Multiple solutions merge behavior: when you prepare to distribute your managed solution, the target environement may have multiple solutions installed or that other solutions might be installed in the future.

Construct a solution that follows best practices so that your solution won't interfere with other solutions.

According to Microsoft docs: regarding the multiple solution merge that although every effort is made to preserve the presentation, some incompatibilities between customizations might require that the computed resolution change some presentation details in favor of maintaining the customization functionality.

I hope this helps

Malla reddy(@UK365GUY)
#365Blogpostsin365Days

Saturday, 22 April 2023

{Know} Segmentation Solution in Power Apps & Dynamics 365 Apps

Hello Everyone,

Today i am going to share my thoughts on Segmented Solution.

Lets gets started.

Segmented Solution: Solution Segmentation is when you add the required components to your development unmanaged solution is known as Segmented solution.


Lets see this in action.

Sceanario: Suppose you want to add an entity "account" to your solution.





Now you click on the entity and all the entities will be displayed.

Choose "account" and click ok.




Now choose the form you want to add and click finish.






1. Include entity metadata:  if you check this box, it will include only metadata related to the entity not the forms, views and related entities. Metadata includes entity properties, like auditing. duplicate detection
 and change tracking.


2. Add all assets: It will include all the components related to the entity selected.



Now you can select the field required to add to your solution.






Now add all assets for the case entity(table)





Once you clicked on the finish another pop will appear 


There are two options

1. Yes, include requried components:what that mean is the solution you are going to import into target environment dont have this entity components, so you can check the box to include.


2. No, do not include required components: If the entity you have included in this solution  is already available in the target and its related components already exists, so you can check the box, not to include into the solution.


Now you can include the contact into your solution and add then field "anniversary" field.


So your segmented solution created contains three entities "accounts, case, contact" and each entity have only components that were chosen.





Limitations of segmented solution:
1.Solution size is limited to 32 MB
2. Number of solutions is limited by Microsoft Dataverse capacity
3. Number of objects in a solution is limited by Dataverse capacity

 

I hope this helps
Malla Reddy(@UK365GUY)
#365Blogpostsin365Days

Friday, 21 April 2023

{Know} ALM Solution concepts

Hello Everyone,

As i am blogging regarding Application Lifecycle Management.

So today i am going to share solution concepts that are being used in Microsoft Power Platform.

Lets gets started.

Key solution concepts:

1. Two types of solutions:  Unmanaged Solution & Managed Solution.

Unmanaged Solution: Unmanaged Solution is used in the development environments when we are making changes to the application. 

Unmanaged solution can be exported either unmanaged or managed. So the exported unmanaged solution can be checked into the source control system. 

Unmanaged solution should be considered as a source for the Microsoft Power Platform assets.

Note: When an unmanaged solution is deleted, only the solution container of any customizations included in it is deleted. All unmanaged customizations will remain uneffected and belong to the default solution.

Managed Solution: Managed solutions will be deployed to non development environments in simple terms.

Which may be UAT, SIT and Production environments.

A managed solution can be served as independently from other managed solution;

Note: As an ALM best practice managed solutions should be generated by exporting an unmanaged solution as managed and considered a build artifact.

Managed solutions can't be edited directly, instead if you want to edit it, create an unmanaged solution and add the managed components into it and make changes and import into the environment as managed solution, so that changes will be layered. for managed properties click






Makers and developers work in development environment using unmanaged solutions, when the development work completes then export them to other environment like UAT as Managed Solutions.


NOTE: We can't import a managed solution into the same environment that contains the orginating unmanaged solution. to test a managed solution, we need a separate environment to import it.

When you delete a managed solution, data will be lost from custom entities that are part of managed solution and data stored in custom attributes that are part of the managed solution on other entities that are not part of the managed solution.


2. Solution components: Like entity, attributes, relationships, metadata for detailed list click here




3. Lifecycle of solution: Solutions support these actions: Create, Update, Upgrade, Patch are the lifecycle of the solution.





4. Solution Publisher: A solution publisher will be the owner of the solution, which also contain prefix, where the prefix will be used when a new attribute is created it will be used as part of the schema name for example: gmr_businessunit, where gmr is the prefix.







5. Solution and Solution components dependencies: Solution components dependencies will appear when a managed/unmanaged solution is installed on top of the already managed solution.

Remove dependencies: here


Dependency tracking for solution components: here


Hope this helps

Malla Reddy(@UK365GUY)
#365Blogpostsin365Days

Thursday, 20 April 2023

{Did you know} Application Lifecycle Management Environment strategy

Hello Everyone,

Today i am to share my views on the ALM Environment Strategy.

Lets gets started.


ALM Principles: It needs individual environments for app or solution development and production.

So basically basic ALM can be performed with Development and Production environments.

Best practise is to have atleast one Test environment which is separate from development and production environment.

Some organisations use other environments like UAT(user acceptance testing) system integration testing(SIT) and training too.

Why development environment?


Because any development for app or solution can be done on it and also we check the changes. Separate environments helpful to reduce issues when a developer affects another while making changes. 


Development environments?


You can discuss this like how many development environments required? here

Similarly you can provision environments from source code? here

What are the dependencies on my environments? here


ALM other considerations?


ALM should have a minimum of DEVELOPMENT, UAT AND PRODUCTION environments as any changes made on the development environment can be tested in the UAT and prior to deploying to Production.


Multiple geographical environments?



Power Platform have service updates frequently so service update schedule as environments are updated across the globe.

According to Microsoft there are total six stations, its defined by geographical location.

So any service update is done in sequencial order for example: station 3 service updates are applied before station 4. 

i.e so its common for environments that are in different stations to have different versions at a certain point in time.


Things to be considered when importing the solution and environment version:


1. You can import newer version into an environment than the environment where the solution was exported.

2. We can't import a solution into an environment that's an older version than the environment where the solution was exported. Because there might be some missing components or required funtionality in the older environment.


Aligning environments with service update stations:







                                                                Image source Microsoft


Suppose we have a production environments in Canada and the United States. In that case your development environments should be in North America(station 5) and not in Canada (Station 2). so that your development environments will always be the same or an earlier version than your production environments, which will decrease solution import version conflicts.


I hope this helps.
Malla Reddy(@UK365GUY)
#365Blogpostsin365Days

Wednesday, 19 April 2023

{How to} Resolve Relationship Mapping fields between Opportuntiy and Quote entities Dynamics 365 Sales

Hello Everyone,

Hope everyone doing good.


Today i am going to share simple OOTB feature which some of them aware but i want to bring this to my blog readers.


Scenario: Suppose there is a requirement to transfer some data from Opportunity to Quote when an Opportunity is qualified automatically. 


Like When a lead is qualified some of the data will be automatically transferred to Opportunity, do you know how this is happening without any code written, its because of "Relationship Mapping" from the 1-N relationship between entities.



Lets see this in action.


So for this example i have created a business unit lookup field on the Opportunity entity, and also on the Quote entity same business unit lookup field is created.


Now i want to carry same field value of business unit of Opportunity to business unit of Quote.


Create a solution and add the opportunity and quote to it.


Steps taken:


1. Create a business unit lookup field on the opportunity


make sure select the target entity for the business unit field as 'BUSINESS UNIT' 


2. Similarly create the business unit lookup field on the Quote entity too, same as step 1.

3. Create a Relationship mapping. 




4. Once Opportunity and Quote relationship selected, you need to open the relationship and click on the "mapping" on the left side of the screen, 

Then mapping the fields like below screenshot.




5. Publish the changes on the solution.


6. Create an Opportunity fill the "busiess unit" as UK and qualify the  Opportunity






As you can see from the above screen when you qualify the opportunity prompt to create a  Quote.



Now you will see the Business unit has a value as UK on the next screen.





So its that simple to add relationship mapping and OOTB field mapping between the entities.

For more information please visit Microsoft Docs


I hope this helps.

Malla Reddy(@UK365GUY)
#365Blogpostsin365Days



















Tuesday, 18 April 2023

{Know} Tools Components and Process for Application Lifecycle Management

Hello Everyone,

Today i am going to share components, tools and processes required to implement ALM.

Lets gets started.

Environments: They serve as a container for all apps, its to store, manage and share your business data.
They serve as a container to separate apps that might have different roles, security requirement, or target audiences.

Note: Each environment will have one Microsoft Dataverse Database.


Also when we create a new environment, choose the Dynamics 365 apps like Dynamics 365 Sales, Service, which are required now or in future. If you dont want them then not to install which are not required otherwise they will create dependency issues when we deploy solutions between ennvironments.


Environments used in ALM:

With the Power Platform admin center, you can create the environments:


Environments types:

Sandbox: Its a development environment, in other terms non production environment.

Production: Its a LIVE environment for your organisation, where business users will access day to day activities for sales, customer service, marketing, field service.

Developer: Power App Develper Plan gives access to Power Apps premium functionality, Dataverse, Power Automate for individual use. its a single user environment and its not used to run or share production apps.


Default: Its a default environment created for each tenant and shared by all users in that tenant.




Who should have access to these environments, Microsoft Power Platform Provides environment level admin roles to perform tasks.

Development environment will have App Makers and developers have access to it.

Test environment: Testing users and admins will have access to it.

Production environment: Admins and app user and they should have access privileges to perform the tasks.

Default: By default every users will have create and edit apps permissions, so create an environment for development activities and testing and production and provide appropriate permissions for them.


Solutions: Solutions are used to transfer apps and components from one environment to another, they only contain metadata and certain entities with configuration data.

Source Control:




Source control otherwise known as Version Control, when you makes any changes to the solution and deploy to other test or production environment, those changes by multiple users and it is maintained through source control to revert back to previous state if something is wrong.

Source Control helps businesses to achieve healthy ALM because the assests maintained in the source control system are single source of truth or otherwise a single point of access and modification for your solutions.


Source control process using a solution:

Two main paths we can use.

1. Export the unmanaged solution and place it as unpacked in a source control. so the build process imports the packaged solution as unmanaged into a temporary build environment(sandbox environment). then export the solution as managed and store it as a build artifact in your source control system.

2. Export the solution as unmanaged and also export the solution as managed and place both in the source control system. Although this method doesn't require a build environment, it does require maintaining two copies of all components(one copy of all unmanaged components from the unmanaged solution and one copy of all managed components from the manage solution.

Automation: 

Automation is a key part of the application lifecycle that improves the productivity, reliability, quality and efficiency of ALM. Automation tools and tasks are used to validate, export, pack, unpack and export solutions in addition to creating and resetting sandbox environments.

How the Source control being used by your development team

Consider how your development team will be work together as a team to build the project.

some tools and workflows - such as those provided in GIT, GITHUB, and Azure DevOps were designed for the express purpose of improving communication and software quality.

Note: Working with configurations in a solution system can create challenges for team development. 

Organisations must orchestrate changes from multiple developers to avoid merge conflicts as much as possible, because source control systems have limitations on how merges occur.

Recommendation: Avoid multiple people make changes to complex components, such as forms, canvas apps at the same time.


Continuous integration and deployment:


You can use any source control system and build a pipeline to start with for continuous integration and continuous deployment(CI/CD).

We are discussing about the Azure DevOps, Github.

Github is a development platform used by millions of developers.

Azure DevOps provides developers services to support teams to plan work, collaborate on code development, and build and deploy applications.


You need the following:

1. A GitHub account, where you can create a repository

2. An Azure DevOps organisation




Licensing:
 
In order to use Power Platform, Power Apps, Power Automate, users will require a license such as per user or per app license or Dynamics 365 app license.

ALM Considerations:

When you consider ALM as an integral part of building apps on Microsoft Power Platform, it can drastically improve speed, reliability and user experience of the app. it also ensures that multiple developers writing code and citizen developers, can jointly contribute to the application being built.

I hope this helps

Malla Reddy(@UK365GUY)
#365blogpostsin365days

Monday, 17 April 2023

{Did you know} Microsoft Certification Study Material Guide

Hi Everyone,

In this blog post i will share the useful link for the Microsoft Certification Material Study Guide.






Here is the link for it Certification Guide 


I hope this document will help all aspiring for microsoft certifications.

All PL Series material also present in the link provoided above.


I hope this helps.

Malla Reddy(@UK365GUY)