Category Archives: WebAPI

Making a better User Experience with PowerApps Component Framework from sketch – Part 4 – The Final Showdown

Published / by AK / Leave a Comment

You can read previous post Part 1, Part 2 and Part 3.

Seeing is believing

It took me 2.5 days to learn and figure out the design and new technologies I need to build the component.

Less than half a day, the mock version of the component was completed. The component was loaded on the form, the dialog was shown with the mock file list, the Flow was triggered to attach a hard-coded SharePoint file to an email as an attachment.

Now, I can prove the team that the PCF control works. I can show it to users how the component can change their life drastically.

When users saw the new UX, it just blew away them. They just forgot the inconvenience with the out-of-the-box user experience. We shot down Top 1 issue from their bounty list.

Keep yourself connected

Though the mock version was smooth, there were a few issues (as expected) I faced. When I tried to use WebAPI in PCF, it always return null. I checked my old PCF which used to be work. It was not working anymore. I looked at other PCF examples from the community. All looked same as mine. Mine was not working. I had no clue.

So, I reached out Natraj (God Mode of PCF). He kindly showed me the direction. It turned out PCF team had introduced <feature-usage> tag in manifest. I had to include WebAPI feature in manifest file to use WebAPI. It was a life saver.

A blocker? Reach out to the community.

You don’t have to be alone solving the issue.

Coming to the end

Just over 1 day of building and trouble shooting, I had a fully working version of the component. In fact, the total build time was less than the initial design and exploration.

If you ask me “Would you spend more time thinking and playing than actual building?”, my answer is “Always”.

I encourage my colleagues to spend more time exploring than completing tasks. Completing the task is the last thing I worry. To me, understanding fundamentals and visualising the process are more important than just completing the task. Once you fully understand it, the rest is a piece of cake. You don’t need to look back. You can keep moving forward.

Limitations or future enhancements

There are many limitations and a few things I couldn’t include in this first version.

  1. Support sub-folder in SharePoint – The component does NOT currently support the navigation of sub-folder in SharePoint. I had the working FetchXml query and will add it in next version.
  2. Support attaching documents from Notes – I want to allow users attaching from Notes of an associated record, similar to SharePoint documents.
  3. Support local file attachment – This will make the component one-stop shop for attachments. You can attach files from SharePoint, Notes and local files.
  4. A managed solution package (with potential AppSource)


After I posted the component in LinkedIn, a few people reached out to me how to configure the component and its Flow. I had privately responded to them.

The component accepts 3 properties

  1. Regarding Id – Can be bound to any text field. However, I recommend creating a separate text field as I need to update it’s value to trigger onChange event in Dynamics to refresh the grid. Currently, it is the only supported way to refresh the grid.
  2. SharePoint Site URLs – You can include multiple site collection addresses with comma separated value. For instances,,
  3. API/Flow URL – The URL of Flow end point. It will look like this “…invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=…&spsite={0}&spfilepath={1} . Get my Flow here. Once you imported the Flow, copy the HTTP URL from the trigger. Then, append the URL with &spsite={0}&spfilepath={1} and set it as property value.

Last step is to hook up JavaScript to refresh the grid. Create a JavaScript web resource or update the existing one with the following script.

function refreshAttachmentGrid(executionContext) { 
var formContext = executionContext.getFormContext();
var attachmentGrid = formContext.getControl("attachmentsGrid");

Then, add the web source to the Email form and add onChange event on the attribute you bound with PCF to call refreshAttachmentGrid function.

That’s all you need to configure to use the component.

I hope you enjoy this mini-series of blog. You can read Part 1, Part 2 and Part 3.

I will be back with another cool PCF that works in both model-driven apps and canvas apps. Stay tuned. Bye for now.

Read Office 365 Message Centre using Office 365 Management API

Published / by AK / Leave a Comment

I started my career as a web developer. Since then it is one of the best decision I have ever taken. Web has been evolving and because of it, low code platforms like Microsoft Flow makes our life a lot easier. In this post, I am going to show you how to read messages from Office 365 Message Centre using its API.

Office 365 Management API is well documented at

Since it is web api, Microsoft Flow can easily make HTTP request and parse the response. To do it, let’s register an app in Azure Portal first. As we are going to use it from Microsoft Flow, you need to create Web App / Api type application. Another point is to grant the correct permission to the app. Its permission should be set as below.

Permissions to read messages

Permissions to read messages

Ensure you click Grant Permissions after choosing correct permissions. Otherwise, the authroisation will fail.

After this, the rest is quite straight forward. I have created the following Flow. In general, it will

  1. read the last message time from my Google sheet
  2. check the value of last message time. It sets the correct StartTime condition in HTTP step so we won’t be retrieving same messages over and over again.
  3. parse the data and insert into my Google sheet

Message Centre Flow

Message Centre Flow

HTTP request step is setup as below. It is quite straightforward. Please note we need to filter StartTime properly.

Office 365 Management API HTTP Request

Office 365 Management API HTTP Request

Once the Flow is executed, all messages are nicely inserted into my Google sheet.

Messages in Google Sheet

Messages in Google Sheet

This is all because of the power of Web. Of course, Microsoft Flow makes things easier. That’s all for now.

Passing current login user of Microsoft Dynamics CRM Portal to external web app

Published / by AK / Leave a Comment

You can get the detail of current login user in liquid template va user liquid object. There is another way you can get the current login user via XHR call.

Microsoft CRM Portal has built-in API to generate JWT of current login user. The API is at https://<crm portal url>/_services/auth/token and returns JWT. This JWT is nothing but a JSON object encrypted using RS256 algorithm. So, anyone can decode it. Other words, anyone can encode it also.

You sometimes need to pass the current login user information to external web app. Since it takes very little effort to generate a JWT and pass it to your external website, it is very easy to bypass the security. Therefore, you will definitely want to verify the authenticity of generated token too ensure the token is generated from trusted source (in this case, your CRM portal).

The beauty with JWT is you can verify the signature of token using public key. If you are not familiar with PKI, the process generally involves the source or CRM portal which generates a token using its private key (which is already handled in CRM portal), and the target or your external web app which verifies the authenticity of the token using public key. To do this, get  the public key of your CRM portal at https://<crm portal url>/_services/auth/publickey.

The order of the whole process is

  1. Pass JWT token as a parameter in a web request/link to your external web app
  2. In your external web app, get public key from CRM portal and verify the signature of the JWT contained in web request

That’s easy, simple and neat. Right?

Next time, we will have a look at Azure AD B2C configuration to authenticate users, which requires more configurations and adds a little bit of complexity.

Accessing Dynamics 365 WebAPI as an application user without using ADAL

Published / by AK / Leave a Comment

Microsoft has recently posted the documentation for using Postman with Dynamics 365 WebAPI at This prompts you to login into the application using your credentials to generate a bearer token which is passed to Dynamics 365 WebAPI when a request is made.

However, we, sometimes, need to use an application user to access WebAPI, either for integration testing purpose or for implementing automations. Microsoft has documented server-to-server (S2S) authentication using Azure Active Directory Authentication Libraries (ADAL) at

Although I am a developer, I strongly believe we can (should) write a program only when a process can be manually done. Therefore, tools like Fiddler, SoapUI, Postman are essential tools to me when it comes to testing WebAPIs.

Now, I will show you how we can generate an access token using an application user in Postman, assuming you have already created an application user. If you need detail steps to create an application user, please follow instructions at

In Postman, let’s create a few Postman environment variables.

  • TenantId – to store GUID of Azure Directory ID
  • D365Url – to store the URL of Dynamics 365 instance
  • D365AppId – to store Azure Application Id
  • D365AppSecret – to store Application secret
  • D365Bearer Token – to store generated access token

Environment variables

Environment variables

Then, let’s create a new POST request to{{TenantId}}/oauth2/token with following data.

Token request

Token request

Now, send a request and it should return an access token (assuming an application user has been correctly setup).

Access Token

Access Token

Now, we need to store the access token to our Postman environment variable called D365BearerToken so that we can re-use it accessing Dynamics 365 WebAPIs. To do this, we need to write a simple script under Tests area.

Writing tests

Writing tests

Pretty easy, right? Now, let’s create another GET request to retrieve the version number of Dynamics 365 instance. The request’s authorization type should be set to ‘Bearer Token’ and its token value should refer to our Postman environment variable D365BearerToken.

Retrieve version

Retrieve version

Now, you can test any WebAPI calls using an application user without relying on ADAL.

What’s next?

Using the same approach, you are not limited to Dynamics 365 ODataQuery in Flow/LogicApps. You can now call any Dynamics 365 Messages using the same approach and perform various tasks.