Future of developers in Power Platform

Generally all my posts are problem-solution type posts. I never write anything that is purely my opinion. But, considering the recent developments, I thought I should sit down and write down my thoughts. Before we even consider whether developers have a future in Power Platform, we need to first delve into the historical context of the developer’s role and their tasks in Dynamics CRM.

In the beginning of time

I come from a technical background, starting with ASP.NET WebForms, C# and Dynamics CRM OnPremise. Back in those days my role mostly revolved around Plugin, custom workflow assemblies, a bit of JavaScript to do data validation, hiding/unhiding or enabling/disabling fields. I also occasionally had to use Deployment Manager to do some backup/restore or UR installations.

A CRM Developer had to just know C#, CRM SDK, understand a bit of JavaScript to write crmForm.all. You never had to be highly skilled in these languages, since you need to know just enough to write a plugin, custom workflow and JavaScript. This might also be the case because CRM developers were previously C# or SharePoint developers. Since your code is being run in a managed environment, you did not need to worry about a whole lot of things a .NET Developer needed to worry about like caching, multi-threading/parallelisation, memory leaks, unit tests (💣).

ALM was non-existent because there were no concept of Solutions. Even when Solutions were introduced, there was not a whole bunch of enthusiasm for Managed Solutions, which is, I would say, is still the case. Most people just used unmanaged because it was the default. A developer’s role in the ALM (?!) front was to export the solution on DEV and import the solution into TEST/PROD, and keep a copy of the solution zip file in shared network folder.

Then came Solution Packager (2012), AdxStudio ALM Toolkit (2013), XRM CI Framework (2014). These along with TFS helped folks to enable unpack/checkin/repack/deploy the solution. There were only a few people who were passionate about ALM back then, even with this new tooling, since it was just as easy to take a database backup (in the OnPrem world), export and import the unmanaged solution, and restore the database from backup if there was some solution issue.

Once the size of projects grew, along with the number of other developers in team, it became necessary to write unit tests and integration tests. Everyone was simply adopting what was available in the .NET world. I was using NUnit, Moq and Fakes. Then came FakeXrmEasy (2015), a testing framework specifically for Dynamics CRM. It became easy to do unit testing by setting up test records in-memory and use the fake execution context to validate plugin/workflow behaviour. Jasmine and Sinon.JS was used for testing client side code, but these were front end developer frameworks, not Dynamics CRM specific.

So, by the end of 2016, Dynamics CRM developers were mostly doing plugin, custom workflow, JavaScript development, deployment, unit testing and DevOps using TFS. Since this is not based on feedback from other developers across the world in 2016, you could also interpret this as what I was doing back in those days.

Project Sienna – The one that got away

My only encounter with precursor to canvas apps, which was known as Project Sienna (2013) was very brief. As someone who was doing full-time dev work by this point, I downloaded the app to purely to play with it, drop a few controls to understand what it was doing, and lost interest because I compared it to what I can do I in a WinForms application or ASP.NET application. As someone who can build apps, it felt like a downgrade rather than a productivity addon. So, my life continued to revolve around mostly C#, JavaScript and Dynamics CRM.

CRM Online vs OnPremise – EV vs Petrol

My first encounter with CRM Online was around 2013. The biggest shock for me was the lack of access to the underlying database or IIS logs. It took away two items critical to on my debugging process. But it was merely a precursor of things to come, when things transitioned into the SaaS world. But, it was good in a way as you didn’t have to spoil your weekend looking through IIS Logs, Trace Logs, Querying database, trying to come up with a solution. All you needed to do was raise a support ticket.

So when things moved to CRM Online, developers had to just schedule the deployment window, rather then doing database backups, install the Update Rollup etc. This was a good change for developers, as they can focus on dev work and ALM, and not be the Windows Admin or Database Admin.

Lot of times developers had to write SSRS report as well, which meant you need to understand complex T-SQL, create indexes/stats etc. With CRMOnline you can only use FetchXML, which meant that lot of the reports could not be authored. When more SQL Reports moved to PowerBI, due to the limitations of SSRS Report, this gave more time to CRM Developers to work on their areas of interest.

Power Platform – Shock and Awe

Prior to Power Platform, there were two worlds: the world of a CRM Developer who might occasionally do Azure things, and SharePoint + canvas apps world. I think even now, when people say Power Apps they mean canvas app, while the CRM Developers use the term Model Driven Apps, instead of Power Apps. Even though Microsoft is persisting with its unification efforts, these two terms will most likely continue to exist.

Power Apps entered public preview in April, 2016 and it became generally available in Oct, 2016. With GA, we got the Common Data Service and Common Data Model. Even after this, I still continued to do CRM things, only because I was stuck in the CRM2015 OnPremise world, while Power Platform was beginning to take shape. People from the Office 365 E5 world, eagerly boarded the Power Platform rocket ship that started flying million miles an hour.

  • XRM became Common Data Model
  • People got confused between Common Data Model and Common Data Service
  • People were surprised to find that there can be multiple “Common” Data Service per tenant
  • Cool kids started using Flow rather than Workflows
  • It became even cooler to use Logic Apps over Flow
  • Flow/Workflow parity aka “in the fullness of time”, became a fun topic to discuss about
  • Choosing a right CDS connector was the “have you restarted your machine”
  • SharePoint/Canvas apps people still did not care for Solutions, which remained a CRM thing
  • It looked like canvas apps was a gaming platform
  • SharePoint List was the most popular “database” for canvas apps

No Code/Low Code – Reality Distortion Field

The origins of NoCode/Low Code is probably the whole SQL vs NoSQL. While NoSQL is technically feasible, and there are umpteen NoSQL databases that are alternative to SQL Server or Oracle, can you really do everything you can do with code, using low code? Microsoft’s stand these days seems to be that and it is not meant to be a replacement for code, but more like a power tool.

Also with code you commit them into source control, version control, write tests to mitigate bugs, but you still write Power Fx code inside Power Apps without any of these additional “overheads”. You can of course do this now with Power Apps Language Tools and testing to a degree with Test Studio, but back then it was just the appx based deployment and manual testing.

Initially the marketing for Power Apps was around how it is the great enabler, how it is transferring power to the people, how you can quickly build something without writing any code, how you can transition into Power Apps from any non-tech role if you just learn Power Apps. It was all about striking an emotional chord. There were “Happy Gilmore” and “Good Will Hunting” moments, because it is all about an unexpected outsider making an impact. But the campaign inadvertently turned code, IT Admins and developers into bogeyman and gatekeepers. If you don’t use Power Apps/Flow, you might have to write code became the scary proposition. Is writing code that scary?

Screenshot of Bane's speech

It might be inefficient to write code, when you could use low code tools to save dev time. But, that was not how I remember the initial marketing efforts. It was focused on how a regular business user can have the power (#LessCodeMorePower) using low code tools and how they can create apps to make their life better. It was not pitched as a productivity addon for a CRM/Power Apps developer. But, considering that it was predominantly marketing to the “no code” crowd, it is not hugely surprising.

For e.g. consider this tweet from a developer perspective.

If you are a developer it is hard not to feel disillusioned about the future. If one person could achieve something in a short time, that a whole team of developers could not, what does that do to your self-esteem and craftmanship? Does this mean that you should give up on coding and switch to low code tools? Short answer is No.

Developers are not going to end up like Zune*

According to State of Octoverse – 2020 there were 60M+ new repositories created between Oct 2019 and Sep 2020. So, code and developers are not going away any time time soon. Even if low code tools get incrementally powerful year after year, there will always be a gap that needs to be bridged with code. Also, sometimes, it might be much simpler to do something in code, rather than build a 40 step multi-branch Flow or a canvas app with duct-taped Power Fx expressions. If you have strong and inflexible opinion about either low-code or pro-code, the end result might not be optimal. So, it is important to keep an open mind.

There was a period of time, where developers could basically focus only on the CRM components i.e. form script, plugin, custom workflow step etc. and nothing else. As Power Platform + Azure convergence seems to be the emerging pattern in lot of the upcoming projects, developers also need to diversify, rather that rely only model-driven app.

Since Power Fx is now a language, everyone who uses it could technically call themselves a developer. It might start showing up inside other products in the Power Platform.

Power Fx started with Power Apps canvas apps and that is where you can experience it now. We are in the process of extracting the language from that product so that we can use it in more Microsoft Power Platform products and make it available here for you to use. That’s going to take some time and we will report on our progress here and on the Power Apps blog.

https://github.com/microsoft/Power-Fx

Power Fx might take off, or it might not, but pro-developers need to at least keep a watch on how it shapes up. Is it all hype/marketing, or is it something that can improve your productivity? Things can change quite dramatically like Nokia vs Apple or Chrome vs the rest in a short period of time.

https://zdnet1.cbsistatic.com/hub/i/2018/11/26/ba7e61c7-73c6-442d-b93a-c8f1c892ac32/4b4d5930ea733c2cb9f2a299e0b7ee94/apple-nokia-revenue.jpg
Apple beats Nokia in under 2 years
https://upload.wikimedia.org/wikipedia/commons/7/71/StatCounter-browser-ww-yearly-2009-2020_%28updated_until_November%29.png
Chrome took 2 years to become the dominant browser

Here are some areas developers can focus on:

  1. Power Apps Component Framework + React + TypeScript – PCF Components can be used in Power Apps portals, canvas apps and model-driven apps, so it saves lot of dev time since you don’t need to target individual products
  2. Virtual Tables – This is even more exciting now as you get CRUD support
  3. Azure Dev Ops – Citizen Developers are going to rely on the developers to manage the pipeline, releases, review/approve pull requests, work through solution layering, environment variable, connection reference issues etc. Since you might be using this for other Azure components like Azure Functions, Logic Apps etc. this is a good one to learn
  4. Azure Static Web Apps – If you need to build custom portal entirely in code, or single page app to embed inside an existing portal, interact with APIs, this is a good one to consider
  5. Azure Functions – While you might be able to implement what a single Function does using Logic Apps or Flow, it is hard to replicate what Durable Function or a Function with SignalR binding does. Functions give you greater control, since it is entirely code. As a developer in a Fusion team, you might be incharge of creating the API using Functions, expose it use Azure APIM, so that citizen developers can consume it using custom connector
  6. Canvas Apps/Flow/Logic Apps – Even though these are low-code, having code skills might quite beneficial when you write the expressions or Power Fx. It might also be a good opportunity to learn about UX, app design principles, accessibility etc
  7. Power Apps Virtual Agent Custom Skills – While you could call Flow and use the response in a PVA bot, using custom skills is a code first way to do it
  8. Docker – Containerisation and Dev Containers are so useful in getting a consistent dev environment setup. It also gives you the ability to switch between your local machine and CodeSpaces. So, it is good to learn and experiment with this

End of the day, if you love to code and would like to keep coding, learn new things, play with emerging tech, you still have choices, but most of them seem to be in Azure these days. It might not be a bad thing, as you could potentially switch-over to Full Stack or Azure Dev, if low code takes away lot of the opportunities for a developer. It might also end up being better career wise, as having Azure/PCF/React/TypeScript skills might open up a whole new world of opportunities outside of Microsoft partner ecosystem.

Opening Lookups in Main Form Dialog

Main Form Dialog is a new feature in model-driven Power Apps. It was officially released this month (Feb 2020). Along with this, I also noticed today that Microsoft has also quietly added a new event that plays nice with MFD.

The new event is called OnLookupTagClick. This event handler can be used in scenarios where the user clicks on the lookup. Normally, this would redirect the page to the lookup record, but you can block this navigation on OnLookupTagClick, and rather show the lookup record on a modal popup using navigateTo. Below is the sample code on how to do this. Since I ran the code from DevTools console, I am using the deprecated Xrm.Page. If you are running this from a form, you should use the formContext.

Xrm.Page.getControl('parentcustomerid').addOnLookupTagClick(context => {
    context.getEventArgs().preventDefault();
	const tagValue = context.getEventArgs().getTagValue();

    Xrm.Navigation.navigateTo({
        pageType: "entityrecord",
        entityName: tagValue.entityType,
        formType: 2,
		entityId: tagValue.id
    }, {
        target: 2,
        position: 1,
        width: {
            value: 80,
            unit: "%"
        }
    });
})

Have a look at the GIF below to understand the UX of this approach.

2020-02-27_20-40-11

Using PCF to display contact cards

What is PCF?

If you are building Model Driven Apps, you would have realised by now that Unified Interface is the future. Microsoft has made huge investments in this area to ensure that you have an optimal experience regardless of the device or form factor. Unified Interface is composed of several components/controls that help you to visualise and interact with the data.

If you wanted to swap out the control or build a new one that is better than what comes out this box, the only way you could do this earlier was to build a custom webresource and embed it into an IFrame. Using IFrame is clunky, and you had to handle all the complexities of building a responsive interface. IFrame also cannot be displayed on a view, only on a form.

But with the arrival of PowerApps Component Framework, you can build custom components/controls that can be used in fields or view fairly quickly. PCF entered public preview around April, 2019. The are three things that you will be using while developing a custom components/control: PCF, the framework that can be used to build the components, a CLI (similar to yeoman, if you are from node world) that is used to scaffold, build & deploy the control and a test harness to assist you during development.

What do you need to know to build components/controls using PCF

  1. TypeScript (preferable) or JavaScript
  2. NodeJS
  3. Ability to run commands from commandline
    • If you don’t like to live in the commandline, download XrmToolBox tool called PCF Custom Control Builder by Danish
  4. React (preferable)
  5. Office UI Fabric  (preferable)
  6. Edge Dev Tools or Chrome Dev Tools (while build/debug)
  7. Fiddler (while build/debug)

Where do I go to get inspired or assess the capabilities

There are couple of places:

  1. Community Content on PCF Forum
  2. PCF Gallery

In this post I will share a control that I built using PCF that displays the view as a set of cards. Here is how it looks on the contact grid when you choose the Full layout.

Full Layout

You can also display the result in the compact layout.

Compact Layout.png

Clicking on the card takes you to the record, and you can load more records, by clicking on the “Load more” button on the command bar.

In order to install the control, you would first need to install the managed solution by downloading Contact.Card.Component.zip from https://github.com/rajyraman/Office-UI-Fabric-Card/releases

After you have downloaded and installed the managed solution, you can add the PCF component/control to an existing view or new view.

View Properties

As you can see above, I am configuring the view to show the results using “Cards” control, and not “Read only Grid” control. After this you need to configure each property to the correct field on the entity, that you would like be shown on the card.

Card Layout

Card Props

Each property on this control maps to the card as below

Card.png

How do you get the image to display on the custom control?

If you don’t need image on the card, you can skip this step. This is the tricky bit. There is a field on each entity that is capable of storing a image. The name of the field is entityimage. This screenshot should jot your memory.

Upload Image.png

You cannot however, add the entityimage field to a view, as this field is not visible in the View Builder: both classic experience and maker experience. But, entityimage is a valid field, so you can add this field using the awesome tool called “View Designer” in XrmToolBox.

View Designer.png

This allows you to modify both the FetchXML and LayoutXML of the view. Using this tool you can add the “entityimage” field.

Edit View.png

Once you do this, you can see the entityimage field on the view in the classic designer. If you try to open the same view in the modern designer it will fail.

PCF View

After save and publish, you should now be able to use the custom control on the view that it is bound to. You can also use a custom control to display results on the Quick Find as well, using similar update to FetchXML and LayoutXML, but Quick Find does not seem to be supporting entityimage attribute at the moment.

I hope this is an useful control that everyone can use.

Further reading:

  1. Using TypeScript with modern React (YouTube)
  2. Office UI Fabric Controls
  3. Office UI Fabric CodeSandBox
  4. What are custom components (docs.microsoft.com)
  5. PCF Forum

People to Follow for PCF

  1. Andrew Butenko
  2. Andrew Ly
  3. Aung Khaing
  4. Greg Hurlman
  5. Jose Aguilera
  6. Oleksandr Olashyn
  7. Vignesh

Embedded Canvas App: User Settings Utility

User Settings utility is a popular XrmToolBox tool that helps administrators update the user specific settings in bulk, without asking individual users to update them. Here is how it looks:

User Settings Utility.png

I attempted to do this using embedded canvas apps. Here is how it looks:

Business Unit Form

As you can see the canvas app is embedded inside the “Business Unit” form called “Business Unit – Users”. It initially displays a list of users in the Gallery. You can then click on an user record to edit the user’s settings.

Edit Settings

The canvas app currently uses the ModelDrivenFormIntegration datasource, that is the default for embedded canvas app. But, you could very well tweak this app to make it a regular canvas app, and then you would be able to edit the user settings from your phone on the go, which could be quite useful for an administrator.

You can download the managed solution from https://1drv.ms/u/s!AvzjERKFC6gOxDDJp_ZoVc2Pqw7x?e=sNq5Gq. The solution contains the following components:

  1. New view – “Enabled Users for UserSettings” on System User entity
  2. New form – “Business Unit – Users” on Business Unit entity
  3. Canvas app – “User Settings Utility”

User Settings Utility Solution.png

Hope this is a useful tool for admins.

 

 

Flowception: Creating solution enabled Flow with Flow

Solution is a feature that has been used in the CRM space for a long time. Solutions support for Flow was announced last year -> https://flow.microsoft.com/en-us/blog/solutions-in-microsoft-flow/. One thing the post does not mention is that Flows have to be created from the solution record. If you have an existing Flow, that you want to package up into a solution, you cannot do that. To workaround this limitation, I have created a Flow to clone an exisiting Flow and make it solution enabled.

The Flow itself it not that long. Here is how it looks.

The Flow definition fits on a readable screenshot!

The first step is to select the existing Flow that you want to clone, into a solution enabled Flow. This can be done using the Flow Management Connector’s “Get Flow” action.

Solution enabled Flows, like solution enabled canvas apps, are also stored in the CDS database. The entity it used to store the Flow is called Process (logical name: workflow). It stores both the Flow definition, as well the the connection references.

LINQ output

However, the connection references are stored differently between CDS and Flow. Here is how the connections are stored in Flow.

[{
	"connectionName": "shared-flowmanagemen-f22a175e-d99e-4e41-8404-f6823b2d4d5e",
	"displayName": "Flow management",
	"id": "/providers/Microsoft.PowerApps/apis/shared_flowmanagement"
}, {
	"connectionName": "46c0ebf24ba6458f9a582abde1185b12",
	"displayName": "Common Data Service",
	"id": "/providers/Microsoft.PowerApps/apis/shared_commondataservice"
}]

Here is how the connections are stored inside CDS workflow.

{
	"shared_flowmanagement": {
		"connectionName": "shared-flowmanagemen-f22a175e-d99e-4e41-8404-f6823b2d4d5e",
		"source": "Invoker",
		"id": "/providers/Microsoft.PowerApps/apis/shared_flowmanagement",
		"tier": "NotSpecified"
	},
	"shared_commondataservice": {
		"connectionName": "46c0ebf24ba6458f9a582abde1185b12",
		"source": "Invoker",
		"id": "/providers/Microsoft.PowerApps/apis/shared_commondataservice",
		"tier": "NotSpecified"
	}
}

As you can see one is an array and another is an object. So, this means the connection JSON has to be reshaped, when we create a Modern Flow Process record, directly in CDS. We will use select action to reshape the data, and then do a replace to cleanup the JSON.

Flow Connection JSON.png

Connection References

The action below is the one that creates the Solution enabled Flow. You create the “Process” record using the CDS connection, and populate the Flow JSON in “Client Data” field.

Create Workflow.png

This is the formula I use in the concat.

concat
(
	'{"schemaVersion":"1.0.0.0","properties": { "definition": ', 
	body('Get_Flow')['properties']['definition'],
	', "connectionReferences": ', 
	variables('connectionReference'), '}}'
)

This creates the JSON that is accepted for the “Modern Flow” process record.

In the last step we activate (start) the newly created Flow.

Enable Flow.png

The Flow’s GUID is stored in a field called “workflowidunique” on the Process entity. So, we can use this to the retrieve the Flow, and activate it.

The crazy part of this Flow is that I was able to run the Flow on itself and add it to the solution, hence the title of the post.

Flow run.png

You can now add the Flow into the Solution, from web.powerapps.com

Solution.png

The newly created Flow, will have the same step Flow name, you specific in the first Get Flow step, prefixed with “Solution: “

Add Flow.png

The solution with the Flow can now be exported and imported into a new CDS environment. I hope this helps you to package some of you old Flows into a solution. This Flow can further improved by listing all Flows in the environment and doing the same process or cloning it, rather than specifying a specific Flow at design time.

You can download the Flow from https://1drv.ms/u/s!AvzjERKFC6gOwWC7Ywi5fgguPW1s

If you have any comments/feedback, please share them on the post or tweet me @rajyraman.

Role based Canvas Apps

The inspiration for this post is this post from Geetha -> https://svaghub.wordpress.com/2018/11/03/role-based-security-in-powerapps-using-spgroups/. The idea is to basically use Flow to check what kind of permission the current user has, so that some functionalities can either be lit up or hidden in the canvas app. In her post, Geetha was using SharePoint user group to get this information. Being from a CRM background, I want this to be retrieved from CDS + I am not a big fan of SharePoint.

Attempt 1: Use DataSourceInfo(‘Users’, DataSourceInfo.CreatePermission), to check if the current user can create Users, which means they are Sys Admin. But, there seems to be a limitation on DataSourceInfo, which means it does not return the correct permissions for CDS entities. It always returns true, which is not correct. So, this attempt was not successful. This would have so much easier if it had worked, as all the logic would be entirely in the canvas app.

Attempt 2: Flow magic. I didn’t want to head this route, but since DataSourceInfo did not work, I had to use Flow to solve the problem. Solution is one of the restricted CDS entities. Only certain roles have access to read this entity OOB. Below are those roles.

Privileges.png

So, I am using this as the flag to show or hide canvas apps controls. Below is my Flow.

Flow.png

There are two parallel branches, one if there is an exception while retrieving Solution records, which means that the user cannot read “Solution” entity and another branch if they have read privilege on “Solution” entity. Depending on which branch the Flow takes, “canread” can be true or false. I can use the result to show or hide controls on the canvas app. The two branches have the appropriate “configure run after” set.

configure run after.png

Branches.png

The clunky bit about this, which I don’t like is that fact that Flow will report that the execution has failed, when Flow takes the “Cannot read Solutions” branch.

Flow result.png

In the programming world, handling an exception appropriately and continuing like nothing happened, is not considered a failure, but it looks like Flow has a different opinion on this.

Potential improvement to the design: Create a new CDS entity called “Canvas App Permission” and create attributes on this entity, to manage which areas in Canvas App should be shown or hidden. Create multiple records of this new entity and assign this to teams or individual users, depending on how you want the permissions to be applied in canvas apps. The Flow can then retrieve this entity, and PowerApps can use this result of the Flow to hide/show areas or functionality.

Hope this is useful. Credit to Geetha for coming up with the original idea.

Building Spirograph using PowerApps

Over the past few weeks, people have been demonstrating some cool games, built entirely using PowerApps. The reason being, that there was a contest from ThoseDynamicsGuys. If you are interested in finding out about some interesting games from this contest, watch this video from Mr.Dang himself -> https://www.youtube.com/watch?v=0-ZWqs_emQA where he reviews the games.

There were some apps that caught my eye during this period:

  1. Power Flappy by Scott Durow
  2. Power Roulette by Geetha Sivasailam
  3. Coin Dog by Makato Maeda
  4. Air Resistance by Nagao Hiroaki

I was especially fascinated by what Scott and Makato accomplished with the side scrolling nature of the games, how Geetha managed to rotate the roulette as there is no rotate angle property on images and how Nagao managed to calculate the trajectory and resistance of the ball. The first step to learning is to understand how other people do it, so I spend 4-5 days to understand how these apps have been developed.

I then wanted to develop something of my own, using the concepts that I had learnt. Spirograph was the first thing that I thought of. The easiest part was to get the equations to calculate x and y. I had to then learn the basics of starting and stopping a timer, and how to create a sense that the pattern was being “drawn”.

Since image control can render SVG, I decided to try this approach. My first challenge was how do I calculate the x and y on every tick of the timer. So, I decided to follow the approach demonstrated by Brian Dang, that involve checking and un-checking a toggle control.

Every time the toggle is checked, I can increment the iterator variable and calculate x and y for the line to be drawn and the string for the SVG path with all the lines. In SVG you can draw a line, by moving to a location specifying Mxy and then drawing the line using Lxy. Below is the formula in the OnCheck event of the slider

Set(VarI, VarI+1);
UpdateContext({x:
(((RSlider.Value-rSlider.Value) * (Cos(rSlider.Value*VarI/RSlider.Value))) + (aSlider.Value * Cos(VarI*(1-(rSlider.Value/RSlider.Value))))),
y:
(((RSlider.Value-rSlider.Value) * (Sin(rSlider.Value*VarI/RSlider.Value))) - ((aSlider.Value * Sin(VarI*(1-(rSlider.Value/RSlider.Value))))))
});
Collect(Lines, {Row: VarI,
X: x,
Y: y});
Set(PathVar, PathVar & If(PathVar="", "M", "L") & x & "," & y);
true

I can then simply set the SVG path’s d property from the PathVar variable, that has all the line co-ordinates. Below is the value for the Image property of the Image control that renders the Spirograph.

SVG Path.png

Below a video of the app in action. You can play around with the sliders and be fascinated by the patterns that it generates.

Spirograph.gif

Here are some interesting patterns the app generated.

You can download the app from the PowerApps Community Gallery -> https://powerusers.microsoft.com/t5/Community-Apps-Gallery/Spirograph/m-p/175447

References:

SVG Paths – https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths#Line_commands

Math behind Spirograph – http://www.mathematische-basteleien.de/spirographs.htm

Improving entity forms using embedded PowerApps

I have been looking into scenarios with PowerApps and Flow that can benefit Dynamics 365 Customer Engagement user experience. One of the scenarios that can add value right away is on the entity forms. PowerApps can be embedded as an IFrame on the normal entity forms, and can be used similar to Dialogs to offload some processing to PowerApps and Flow.

Here is the finished product.

Embed PowerApps in UCI

This works without any JavaScript at all in UCI, with the normal IFrame control on the form. Make sure to tick the option that passes the record id and objecttype code and untick cross site scripting restriction.

IFrame Properties.png

No scripts are needed on the form to embed the PowerApp.

Form Scripts

Once PowerApps is in place, the current form context can be inferred using the “id” parameter that is passed on to the form.

PowerApps Initial

I use a known Guid during the design phase to assist me with the app design process, as the PowerApps calls the Flow during the OnStart event and sets the ProblemDetails variable.

A Flow can be associated to an event, from the Action->Flows area.

Associate Flow.png

When the PowerApps loads, it calls the Flow with the Guid, to retrieve the case details. The Flow that responds to PowerApps with these details on the case: Title, Customer Name, Type of Customer (Account or Contact).

Case Details Flow.png

In this Flow I just use “Respond to PowerApps”action and return the three outputs.

Return to PowerApps.png

I used variables to store the Client, which could be the Account’s name or Contact’s FullName, depending on what is on the case. The client type could be either Account or Contact. Account Details and Contact details are retrieved based on the result of the Client Type branch.

For the second Flow, the user presses the “Check” button which performs some additional checks based on business criteria. For this Flow, I used the “Response” action, which allows me to return JSON results. I stored the cases I am interested in on an array variable.

For each case.png

From the variable, I used Select action to grab only the properties I am interested in.

Select.png

I can then use the “Response” action to return these to PowerApps.

Response.png

One weird thing that I encountered in PowerApps/Flow integration, is that I would simply see the result as “True” from Flow, when I tried to return the return the response straight from the variable.

True Response.png

When I used Parse JSON and then Select to reduce the properties it started working. This can happen when there is something wrong with the schema validation, but I am not sure how this can happen when I copy-paste the JSON response from the previous steps to auto-generate the schema.

One more thing: When the Flow that is associated with the PowerApps changes, just make sure to disassociate and reassociate the Flow. I had issues when I did not do this, due to PowerApps caching the Flow definition.

References;

https://preview.flow.microsoft.com/en-us/blog/howto-upload-return-file/

https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/get-sessionid