PowerApps and Microsoft, Where does it fit?

While some people say that PowerApps is Office, others will say PowerApps is Dynamics. They are both correct.

Canvas

Canvas apps si exactly what it sounds like, a blank canvas you create. Here you can choose where to store data: SharePoint, SQL Server, Office 365, OneDrive for Business, CDS , Excel, and many other data sources. For the ease of use I often see storage within SharePoint lists here.

Model Driven

Model Driven app is essentially the Dynamics database, but without all of the bells and whistles that come with Sales/Service/Marketing/Field Service/Project Service etc. It is a clean database where you can start from “scratch” and create fairly complex applications within a short period of time.

Why make a fuss about it?

Well, if you know Microsoft as an organization you will understand me asking this question. Office is now called Modern Workplace, and Dynamics is Business Applications. PowerApps is both, so where does it belong. What team will be the ones promoting the product, and who will gain from selling PowerApps licenses?

Up-sell, Down-sell or Cross-Sell?

Office – “Up-Sell”

While Office consultants se this ass an “Up-sell” and potentially expensive
Office E3 20$ + Plan 1 7$ = 27$
+ Plan 2 20$ = 40$

Dynamics – “Down-Sell”

Dynamics sees this as a “Down-sell”
Dynamics Sales 95$ —> Plan 2 40$ = 55$ savings pr customer

PowerApps – “Cross-Sell”

If you read Jukka’s post about PowerApps maybe what we are doing is creating a bridge between it all, the “Cross-Sell”. I can no longer only focus on Dynamics, and have to embrace PowerApps Canvas and Model Driven. Eventually I think the Office users also will see the benefits of the Model Driven, and then we can start adding value inn all areas to a common database.

On-Premise Data Gateway integration

My state of mind at this moment is hard to describe, but Malin Martnes sendt me this link from Urban dictionary 😂

This is Part 2 of the Gateway SETUP

The final settings

This is where we left off in the last post:

We need to do one config in CRM/CDS before we continue. For the integration to work we need to create a KEY for it to match on. The source doesn’t know of GUID, so I create a key for “Account Number”. In Norway we are lucky that this number is unique and applies to all organization’s.

Open the entity you are integration to (Account for me), and create a new field called KEY. I am choosing to use the “Account Number” field here as my Unique KEY. Remember to publish changes!!

First thing I do is limit the number of accounts while testing.

Then I remove all the blank fields in the KEY, to make it equal to the user input in Dynamics. You don’t have to do this, but chose to for simplicity.

In the next step you choose the entity to connect to in CDS/CRM, and map the field. I am choosing to only map “Name” and “Account Number” during the test.

And the magic continues. Here you can setup how often you wan this awesome sync to happen. Our data is fairly static, so once a week is fine:)

Wait until the query is done, and check out the newly created/updated Accounts in Dynamics. This is just a gamechanger for me.

Pricing (a little uncertain)

As far as I can see/understand, this is using Azure Message bus, and it prices everything to messages pr hour. Below is a snipp from https://azure.microsoft.com/en-us/pricing/details/service-bus/ In my case this would practically be “free”.

Basic
Operations$0.05 per million operations
Standard
Base charge 1$0.0135/hour
First 13M ops/month Included
Next 87M ops (13M–100M ops)/month $0.80 per million operations
Next 2,400M ops (100M–2,500M ops)/month $0.50 per million operations
Over 2,500M ops/month $0.20 per million operations