Friday, 8 February 2019

Delaying a birthday email to the recipients’ local time

07:18 Posted by Elaiza Benitez , , , , , , No comments
It was bugging me in WTF episode 9 that my Flow would send the email immediately when the daily recurrence time had been met. As a follow on from WTF episode 9, I showed in WTF episode 10 how you can identify a Contact's time zone from their address information using a Flow Bing Maps action plus a Bing Maps time zone API.

In this WTF episode I go through how you can delay sending a birthday email based on the recipient's local time zone. It's pretty cool because you can't do this today with a Dynamics 365 workflow and I don't even think it is possible with the Microsoft Dynamics 365 for Marketing app either. Flow on the other hand can handle this requirement without development effort.

Quick recap

WTF episode 9 was about sending a birthday email to CDS Contacts when their day of birth and month of birth equals today's date. I mentioned that the Flow would not be suitable for Contacts in different time zones to my local time (Melbourne, Australia) because Contacts who are in a time zone behind my local time zone would get their email straight away.

For example Contacts based in Seattle would get their birthday email a day early because of how Melbourne is 19 hours ahead. Not ideal to be greeted a day early.

WTF episode 10 paved the way on how to identify a Contact's local time zone where the address information stored in CDS was referenced in the Bing Maps Get Location by Address action followed by identifying the time zone through a Bing Maps time zone API using the latitude and longitude returned from the Bing Maps action. I also showed you how to retrieve the windowsTimeZoneId property form the JSON response.
  • Watch WTF Episode 9 here.
  • Watch WTF Epsideo 10 here.

Combing the two WTF Flows

Actions in both of the Flows can be used in a single Flow to delay sending a birthday email with some minor adjustments and a couple of extra actions. But first, learnt something new from Natraj who is the guy behind Chrome Level Up for Dynamics 365/CRM, a MVP and also currently a colleague 😁

Formatting date and time

In the daily recurrence schedule action you specify the time zone and the start time. 


In the Flow docs.microsoft site it's slightly misinformed which is what I learnt from Natraj. If you enter 'Z' in the start time field of the action it will ignore the time zone entered and use UTC time zone. If you leave out the 'Z' it will respect the time zone entered. In my WTF episode 9 I was entering 'Z' and was entering a UTC date and time. A n00b mistake on my part because of how I was using 'Z' which was causing the action to use UTC, I thought you had to have the date and time in UTC because of what was outlined in the Flow doc. It's OK, everyone makes mistakes and you learn from it.

The documentation Natraj pointed me to was this one which correctly states it.


At the time of writing this blog post I also noticed someone else has commented the same thing in the Flow docs.microsoft page too - scroll down to the bottom. 

Adjustment to a few steps 

1.  In the Compose action that converts the current UTC date and time to my local time zone of Melbourne, I am now interested in 'yyyy.' Previously in WTF episode 9 I was only returning 'MM-dd.' 


2. In the Compose action that splits date values into an array, I can now reference 'yyyy.' The year value is set within another Compose action.


3. One thing I forgot mention in my vlog was that I am also using an Apply to Each action which will perform the actions based on the list of records returned. In this Apply to Each action is where I am checking the local time zone of the Contact through the HTTP action.

In the HTTP action that calls the Bing Maps Time Zone API Given location coordinates, find the time zone of the place, I am referencing the CDS Address 1 Latitude and Address 1 Longitude fields. Since this is a Flow that will be triggered on a daily basis, I have another Flow that triggers on create of a Contact where the Bing Maps Get Location by Address action is used to identify the Latitude and Longitude from their address information (show cased in WTF episode 9).

What I did to extend the Flow

Convert Time Zone action

I am using the Convert Time Zone action to set the desired time of when the birthday email should be sent. For example, I want the birthday email to send on the day of their birthday at 8am their local time. Remember, the date and time needs to be in the format of UTC date time format.

In order for the Base Time value to be set, this is where we have to reference outputs from actions in the Flow. The first one is to reference the compose action that contains the 'yyyy', followed by 'MM' and 'dd.' This makes up the date value. For the time value, simply enter the desired values for HH:MM such as 08:00 which represents 8am in the local time zone.

The reason why I adjusted the Flow by adding the Compose action that retrieves the 'yyyy' in the array is so that the Flow will continue to work whenever a new year starts 👍 No manual intervention required.
For the Format String value it has to be in the UTC Date time format.

For Source Time Zone value you will need to reference the local time zone of the contact which is achieved using the Compose action that has retrieved the windowsTimeZoneId value from the Bing Maps time zone API. 

For the Destination Time Zone you need to use UTC. Why? A couple of reasons
  • Flow uses UTC date and time for the Delay Until action which is what will be used to delay sending the email until it equals 8am in the recipient's local time zone
  • Using UTC as the time zone will account for Daylight Savings Time of the local time if it is in affect. If you chose a non-UTC time zone such as Melbourne, it will be behind by 1 hour which is what I found when playing with this.
Your Convert Time Zone action should look like this:


Delay Until action
As mentioned earlier this action will delay sending the birthday email to the local time of the recipient based on the set date and time value in the converted Base Time from the Convert Time Zone action. Then simply add the Send Email action as seen in WTF episode 9.

Yay

The Flow will trigger as per the Daily Recurrence action. Flow will return the list of CDS Contacts whose day of birth and month of birth equals today's date and will send in their local time using the converted base time from the Convert Time. Pretty cool!


This screenshot shows what the UTC time is that represents Wellington Daylight Savings Time.

In Flow you can see that it had correctly converted the desired set time of 10.22pm (in Wellington (which was 8.22pm Melbourne time when I was vlogging). For a more realistic time if this was a live Flow, this would be set to 8am.

What you need to know

Apply to Each action UI might trip you up

I tripped. I fell. I swore. Haha yeah nah, I was fine but I was scratching my head because I was confused 🤔

I was confused from the UI of the Apply to Each action. When I was testing my WTF Flow I had a contact in Seattle, USA and a contact in Wellington, New Zealand. I set the Base Time in the next few minutes for the Wellington time zone so that I could check it does work. When the Flow ran the Apply to Each action appears grayed out.


I interpreted this as it's not working for either contact. I was watching the clock like a hawk and every time the delayed time was met for the Wellington time zone, I was expecting the record in the Apply to Each action to show green ticks. This puzzled me and I was also frustrated with it because I was thinking "Oh man I am so close in getting this working but it's showing as grayed out." 

Enter John Liu my Flow guardian angel. He explained to me that it would have processed the record in spite of the lack of visual cue. Until all records within the Apply to Each action have completed being processed you won't see the green ticks or red crosses.

When I experiment with Flow I normally create each action one by one and run the Flow to check each action will succeed so that I know what I need to fix if there's a problem before configuring the next action. My Send Email action was the last step, I didn't know if it was actually sending since I was not able to know for sure if the Delay Until action was working as Seattle is 19 hours behind my time. The Apply To Each was appearing grayed out so it confused me.

As soon as I added the Send Email action and ran the Flow again, John was right - the email does send because the record meets all the action criteria even though the Apply to Each is greyed out.

It will show the green ticks or red crosses when ALL records in the Apply to Each have completed being processed. Eventually when 10.21pm in Seattle was met 19 hours later, the Apply to Each action displays the comforting green ticks as the email sent and no other record needed to be processed.


Makes sense but at the same time the UI confused me. It would be good if the actions within the Apply to Each action has visualisation so that you know what has succeeded or failed instead of waiting till all actions of all the records in the liast have been completed. Please note this is when a Delay Until action is used within an Apply to Each action and I also suspect will also occur when a large volume of records are being processed.

Flow concurrency

Another thing you can do with Apply to Each is enable what you call Concurrency. It means that records within the Apply to Each action can be processed simultaneously rather than one at time. I enabled concurrency in my Apply to Each action. I'm going to direct you to John Liu's blog post for further information on the Apply to Each Concurrency setting. 

Summary

You can send a birthday email to a recipient and ensure they get it at a set time within their local time zone. The recipient won't get it at weird hours of the day or a day early. Using a combination of Flow connectors it's possible without code and even accounts for Daylight Savings Time of the recipients local time zone.

Till next time, toodles.

Thursday, 10 January 2019

How to identify a Contacts' time zone in Flow using CDS and Bing Maps

23:11 Posted by Elaiza Benitez , , , , , No comments
Have you ever needed to find the time zone of a Contact? This WTF episode is for you then my friend. Time zone can be easily identified through  the power of a Bing Maps API using a couple of connectors and an expression in Flow. No code!

Bing Maps Time Zone APIs

Before I share the steps with you, I want to talk briefly about the Bing Maps Time Zone APIs available as I'm using one of them in my Flow.

Last year the product team made Bing Maps Time Zone APIs available which you can read from this Bing Maps blog post.

The Bing Maps Time Zone API I am using is "Given location coordinates, find the time zone of the place."


I decided to use this one instead of "Given a place name, find the time zone of the place" because personally I find that using latitude and longitude coordinates would be more accurate rather than using a place, such as a city.

To use the Bing Maps Time Zone API (and Bing Maps Flow connector which I'll get to soon), you need a Bing Maps key. 

I signed up for a Bing Maps Basic Key to use a Bing Maps Flow connector and the Bings Maps Time Zone API. If you are going to be using this in your organisation or if you are a consultant and will include this in your solution design, you need to review the Bing Maps licensing options beforehand to understand if this is a valid solution design.

Steps

1. Trigger

For the trigger of my Flow, I'm using the When record is created CDS trigger. I want the Flow to trigger when a Contact is created.

2. Bing Maps action

The next step in my Flow is to use the Bing Maps action of "Get location by address." This will retrieve latitude and longitude coordinates from address data. We will use the address data from the Contact. The assumption here is that an address is entered against the Contact in the model-driven app in the Contact entity.


When the Bing Maps action successfully returns an output, it looks like the following where you will see the latitude and longitude coordinates.

3. HTTP action

To use the "Given location coordinates, find the time zone of the place" Bing Maps API we need to use the HTTP action and reference the URL provided in the Bing Maps blog post.

https://dev.virtualearth.net/REST/v1/TimeZone/latitude, longitude?key=<bingmaps-key>

Simply reference the latitude and longitude outputs from the previous step, followed by inserting your Bing Maps key.

Result

The Bing Maps API will then successfully retrieve the Time Zone of the Contact. Pretty cool right?

One step further - saving the time zone value

If you need to sore the time zone value of the Contact, you can do so by creating a custom single line of text (string) field in your Contact entity in CDS. The property that will be retrieved from the JSON response is the windowsTimeZoneId from the timeZone object. This is what will be stored in the custom field in CDS.

There's two options that will allow you to retrieve the windowsTimeZoneId property successfully.

Option 1 - without using an expression

You can use the Parse JSON action where you'll be required to copy and paste the JSON response  from the HTTP action to generate the schema.


The next step is to use a Compose action. When you select the Compose action and review the Dynamic Content values presented, you won't see the timeZone object as it is in the array of resources as seen in the JSON response.


If you select resources, you'll then see an apply to each magically appear. John Liu has a blog post that outlines what you need to be aware of when using the Parse JSON action and he briefly talks about this behaviour. When you add another Compose action, the windowsTimeZoneId property will now be visible.


It's not a bad option but it may be confusing.

Option 2 - with an expression

John Liu explained to me that if you don't want to use the Parse JSON action and simplify your Flow, you can use a Compose action to retrieve the windowsTimeZoneId property.


The expression to use is
body('1.2_HTTP').resourceSets[0].resources[0].timeZone.windowsTimeZoneId

My way of explaining this expression is to work backwards:
From the HTTP action, get the windowsTimeZoneId property from the timeZone object which is in the resource array whose parent object is resourceSets.

If you have a better way of explaining this to a non-technical soul, you can tweet to me 😁

The final step

For either Option, make sure you have an action that will update the custom field in the Contact entity.

Summary

By using a Bing Maps Flow action, a Bing Maps Time Zone API and a Compose Flow action you can retrieve the time zone of a Contact in CDS through the address information without code. So cool! Flow is the best.

This WTF Flow is available for download on the TDG Power Platform Bank.

#WTF #FlowFever #FlowAllDayEveryday

Help me get to 500 YouTube subscribers

As mentioned in my vlog, subscribe to my YouTube channel if you haven't already done so as Will from TDG will supporting my milestone achievement by doing a sheperd's pie vlog. This was mentioned in the Power Apps podcast episode where I was a guest and chatted to Shawn, Chris and Will. It would be great to see in Will in the kitchen 😄

Jokes aside, it would be great if I reach 500+ subscribers. I started in 2014 and I'm going to keep going till I can. Thank you!

Thursday, 13 December 2018

Sending a birthday email from CDS fields using Flow

23:00 Posted by Elaiza Benitez , , , , , No comments
This WTF episode came about from fellow MVP Joel Lindstrom. The challenge was to have Flow send a birthday email to Contacts when the day and month of their birthday equals today's day and month. I gave it a go with CDS (Dynamics 365) and Flow.

I did hit a roadblock but I overcame it. Most of my Flows you have seen when I first launched my series was educating you around things you are familiar with today in Dynamics 365 workflows. I'm now going to step it up a notch by showing you more advanced Flows.

In this WTF episode I use a combination of actions and expressions which you haven't seen before in my previous posts. Sending a birthday email doesn't sound trivial but underneath the hood it can be because you need to think about
  • How do I retrieve today's day and month
  • How do I compare this with a Contact's birthday
  • I only want to send birthday emails to Contacts whose day and month of their birthday equals today
  • I need to schedule this on a daily basis
Buckle up cause you're about to Flow with me 🙂

Get Flowing

1. Trigger for the Flow to run daily

This logic needs to happen on a daily basis and the trigger you want to use is Recurrence. This allows you to set the parameters of how often the Flow should execute.

2. Compose action to identify the month and day of today's date

In order to identify today's date, we need to retrieve the current date. To do this we need to write an expression that will allow us to retrieve the current UTC time.  The other thing you need to remember is that date and time in Flow is treated as UTC, it will be in the format of yyyy-MM-ddThh:mm:ssZ

The expression needs to go one step further by converting the current UTC time to the local time zone and because we're only interested in the day and month, we only need to retrieve the day and month value.

For the string value of the time zone, I grabbed it from this Microsoft list. I was accidentally looking at an incorrect link but fellow MVP John Liu kindly pointed me to the right list. Thanks!

To do this we use the compose action.

The expression to use is:
convertFromUtc(utcNow(), 'AUS Eastern Standard Time','MM-dd')

3. Compose action to split the month and day

Now that we have retrieved the current day and month, we need to separate the two values as it's still in a UTC format of MM-dd. To do this we use the split function. The split function in PowerApps is the same in Flow.

The expression to use is: 
split(outputs('Convert_to_Time_Zone') ,'-')

4. Compose action to set the day value

Now that the previous action will provide outputs of month and day, we now need to set the day value in its own compose action so that we can refer to it in our criteria in a later step/action in the Flow.

The previous action provides the outputs in an array so in our expression, we need to reference the second value. 

The expression to use is:
outputs('Split_MM-dd')?[1]

5. Compose action to set the month value

The same applies in this action to set the month value.

The expression to use is:
outputs('Split_MM-dd')?[0]

6. List records to only retrieve Contacts whose birthday day and month equals today's day and month value

List records allows you to target only records that meet criteria. This is where Odata functions come into play. I decided to use the day and month function so that I can check that the birthdate (schema name) field's day and month matches my #4 and #5 compose action outputs.

The expression to use for the filter query field in the List records action is:
day(birthdate) eq '@{outputs('Set_Day')}' and month(birthdate eq '@{outputs('Set_Month')}'

7. Loop through all Contacts that meet the criteria

Use the Apply to Each to perform an action for all Contacts that meet the criteria.

8. Send email to the Contact

The action I demonstrated in my WTF vlog is the Send email (V2). The Flow team recently released an updated action that is a basic WYSIWYG editor. Enter in the email message content and you're good to go.

Spoke too soon

When your trigger your Flow, the Flow will fail. This was a true WTF moment for me as the error that spits out is:


The 'day' function isn't supported.

WHY?! 😭

Flow returns this error because of how the Odata does not support the day and most likely the month function. Even though Odata version 4.0 supports it:


Dynamics 365 does not.

I confirmed this by using fellow MVP Jason Lattimer's CRM REST builder. The message returned is:


So yeah, what now?

Get creative

In the Helper text of the filter query field in the List records Flow  action, it says it supports string and integer. I created two single line of text fields. I went with single line of text field so that I can use the Odata filter operation of "eq"


One field represents the day of the birthdate field, the other field represents the month of the birthdate field.


I then created another Flow that will trigger on create of a Contact to retrieve the month and day of the birthdate value, and populate the fields. Similar actions to my primary Flow is used which I explain my vlog.

Filter query expression take 2!

Alrighty, now we can update the filter query to use the custom fields to check that the day custom field value equals the compose action (#4) that sets the day value AND the month custom field equals the compose action (#5) that sets the month value.

The expression is:
ben_dayofbirthdate eq '@{outputs('Set_Day')}' and ben_monthofbirthdate eq '@{outputs('Set_Month')}'

Voila

Now when the Flow runs, no failures occur and the List records action successfully only retrieves Contacts whose day and month field values equal the day and month outputs from our compose actions.


YES!!!

My final comments

  • Assumption is the contact is in the same time zone that’s used in the convert UTC to local time zone action
  • I have not tried this with large volumes of data, 100,000+ records so am unsure what the performance would be like
  • Schedule recurrence at an appropriate time

Summary

You can schedule sending a birthday email through Flow. Trick is to use a couple of custom fields and the a supported Odata operator in your query. I really enjoyed going through the challenge of getting this to work.

I'm curious to know if others would have approached this differently. Like Dynamics 365/CDS, there's more than one way to achieve a desired outcome. If you find another way, give it a go with Flow and post a tweet by referencing @benitezhere so that I can check it out.

Stay tuned as I have another cool post coming up.

Help me get to 500 YouTube subscribers

As mentioned in my vlog, subscribe to my YouTube channel if you haven't already done so as Will from TDG will supporting my milestone achievement by doing a sheperd's pie vlog. This was mentioned in the Power Apps podcast episode where I was a guest and chatted to ShawnChris and Will. It would be great to see in Will in the kitchen 😄

Jokes aside, it would be great if I reach 500+ subscribers. I started in 2014 and I'm going to keep going till I can. Thank you!

Wednesday, 28 November 2018

How to display a date field value correctly in an email in Flow

23:12 Posted by Elaiza Benitez , , , , , , No comments

In my previous blog post and vlog I covered how to reference related entity data. The last use case was to send an email to the contact associated to the Case where the Created On value is included in the email message content. Currently today we're used to configuring this through the Form Assistant by selecting the Created On field of the Case.



If you do this in Flow using the Get Record action and Send email from Shared Outlook Mailbox, it'll look like the following.


Yes, a true WTF moment. Welcome to another WTF blog post.

Why does it display in this manner?

I stumbled across this when I was in the process of converting my Dynamics 365 workflows into Flow for the Dynamics 365 Saturday NZ conference earlier this year. I knew I needed to use the Get Record action and when I did it was showing up as seen in my screenshot above.

That's when I came across Stephen's blog post in the Flow community site. If you don't know about the Flow community site, you should definitely check it out. There's lots of useful nuggets in there.

Anyways Stephen's blog post explains that Flow treats Date and Time in UTC and talks about using a particular action. The other thing to take note of is that Dynamics 365 also stores Date and Time as UTC. When we see the date and time in the user interface it will be shown in the timezone of the user if it's defined as User Local. For further information on the other Date and Time definitions, refer to this docs.microsoft.com article.

Using the convert time zone action in Flow

This action is pretty simple to understand.


  1. Base time - this is where you need to reference the Dynamics 365/CDS field. In my scenario it's the Created On field of the Case
  2. Format string - this is where you can define the format of the date and time. You can either choose from a list or make your own
  3. Source time zone - this is where you set the value to UTC
  4. Destination time zone - this where you set the value to the local time zone
Once you have this Flow action set up, you're good to go. In your email message you can now reference the convert time zone action. 


When the recipient of the email views the email message they will now see the the date displaying correctly in a more end user friendly manner.

Is there any value in this "extra" configuration step?

OK you might be outraged that you need to go one step further in Flow to get the date and time displaying correctly in an email message compared to the minimal configuration required in Dynamics 365 workflows

However the advantage I see is that you now have the power to format the date the way you want it to. Those who are familiar with Dynamics 365 will know that
  • if you want to have different formatting in Email Templates or in an Email activity created from a Dynamics 365 workflow, you have to turn to some type of custom method
  • you can change the formatting of date and time in Settings so that it shows as desired but this applies globally in Dynamics 365, it's a system wide setting
Here are a few posts that demonstrate people asking about how to change the format of date and time outputs
If you turn to the developer guide on docs.microsoft.com, you'll see a bunch of information on how to to convert date and time fields through code.

By using the convert time zone action in Flow you have the power to choose what format you want as the output in your email message without any code.

Summary

Use the convert time zone action in Flow to display a date and time field value in an email message. If you don't, it will display as UTC in the email message.

If this has helped you, tweet to let me know. Thank you.

This Flow is available in the TDG PowerApps Bank.

Happy Flowing!

#WTF #FlowFever #TDG

Thursday, 15 November 2018

How to reference related entity data in Flow

21:24 Posted by Elaiza Benitez , , , , No comments
What we're currently used to in Dynamics 365 workflows is using the Form Assistant to reference data to a N:1 entity. This is usually when we want to grab field data from a lookup field on the entity form.

In Flow we don't have a Form Assistant to guide us but there is the Get Record action in Flow. It's somewhat different but it's easy to understand. Welcome to another WTF blog post where I explain the Get Record action and what happens if you don't use it.

Use case 1 - reference Company Name

In my first example seen in my vlog, I reference the Company Name from the selected Account in the Customer lookup field of the Case record.


If you don't use the Get Record action and reference the Customer Dynamic Content either in your Dynamics 365 or CDS connector, it'll look like this in your model-driven app.


You'll see the GUID rather than the Company Name. As explained in WTF Episode 1, Flow uses the ODATA APIs of Dynamics 365. It sees the referenced Customer as a GUID.

When you use the Get Record action, you'll be able to reference the Company Name.
The breakdown is as follows:
  • Entity - represents the related entity you want to reference
  • Identifier - represents how you are identifying the record. In this use case we are performing it through the Customer lookup field in the Case entity which is my CDS trigger of my Flow

Once you have inserted your Get Record action you can then correctly reference the Company Name through the Get Record action. When your Flow executes, this time it will correctly display the expected Company Name value.

Use case 2 - Reference email address

This is a common use case when we want to send an email using Dynamics 365 workflows. As seen in my vlog, I'm sending an email to the Contact through the lookup field in the Case. What we are used to when configuring in Dynamics 365 workflow is selecting the Contact in the Form Assistant.


If we do this in Flow, this is what happens.


An error is thrown because Flow again sees it as a GUID instead of an email address.

By using the Get Record action you will be able to reference the email address of the Contact based on the Contact value in the lookup field in the Case record.

Summary

The Get Record action is basically the Form Assistant that you're used to when you want to reference related entity data in Flow. This will allow you to reference fields from N:1 entities.

The next roadblock you might experience is when you reference data and time values in your email message step in Flow, it'll look like this:


In the next WTF blog post I will show you how to get around this.

Stay tuned citizen!

Wednesday, 7 November 2018

Embedding Power BI report and dashboards in Dynamics 365 for Portals

All you die hard fans of displaying beautiful data through the art of Power BI can now rejoice as it's never been more easier to embed Power BI visualizations into Dynamics 365 for Portals. This is another new October 2018 release feature. Get excited cause it's super easy to configure.

What you need

  1. Dynamics 365
  2. Dynamics 365 for Portals
  3. Power BI

How to enable Power BI Integration

Enable Power BI integration through Portal Details. Head over to the Dynamics 365 Admin Centre and in the Application tab, select your Portals instance to open up Portal Details.

In here you'll see a new option called "Set Up Power BI Integration." 


Click on this and Power BI integration will be enabled. Super easy.

Understanding what can be surfaced

You have three options to choose from
  1. Power BI Report
  2. Power BI Dashboard
  3. Power BI Dashboard tile
In my vlog I demonstrated the first two. 

Method to use for embedding Power BI visualizations

You'll need to use Liquid tags with a couple of parameters which can be done through a web page or a web template. These parameters are 
  • Authentication type
  • Path

Authentication type

If using a secure Power BI report or dashboard where only Azure Active Directory authenticated users can view the Power BI, you need to use the tag of "AAD" Make sure the report or dashboard is shared to the required users.

If you want to use a Power BI report or dashboard that will be visible to anyone, you'll need to publish it to the web and use the tag of "anonymous." If you don't know how to do this, check out this article.

For more details on liquid tags for Power BI, refer to this https://docs.microsoft.com article.

Path

This is the URL of your report or dashboard.

Combining the two parameters

As referenced in the docs.microsoft.com article, your tag would be something like the following
{% powerbi authentication_type:"AAD" path:"https://app.powerbi.com/groups/00000000-0000-0000-0000-000000000000/reports/00000000-0000-0000-0000-000000000001/ReportSectionc01" %}

OK, ready to apply tag

You can either insert your Power BI liquid tag in a web page or web template. In my vlog I used a web page that I had created.

Insert the tag in the Copy field of the Localized Content record and you're good to go. Super easy.

Power BI visualization in action

Once the web page is saved, browse to your Portals instance and view the web page. Ta da! Awesome sauce.


What I do like about using a Power BI report is that users can interact with the report still. As mentioned in my vlog I was expecting it to be static and not interactive. Bonus in my opinion that you can interact the report as how you normally would.

Summary

The configuration steps are pretty simple and it doesn't take that long to hit the ground running with embedding Power BI visualizations in Dynamics 365 for Portals. I thought this was pretty cool when I had play with it last month.

I am not a Power BI guru but the person I recommend you check out and follow is none other than MVP CRM Chart Guy,
Cool, have fun configuring!

Thursday, 1 November 2018

SharePoint Document Management for Dynamics 365 for Portals

I'm excited to share with you that SharePoint Document Management is back for Dynamics 365 for Portals. Over two years ago, Donna Edwards, requested that this feature was to be brought back. Short history lesson - back in Adxstudio Portals you could configure SharePoint Document Management. When it was acquired by Microsoft and was included as part of Dynamics 365 Customer Engagement enterprise subscription, the feature was no longer supported.

It has been the most requested feature and the product team have listened. As a MVP I was invited to review and provide feedback to the new October Release 2018 features for Dynamics 365 for Portals. I demonstrated the three new features in the October Melbourne User Group.
  1. SharePoint Document Management
  2. Embedding PowerBI 
  3. New modern Portal editor


In this blog post I will go through the configuration steps required to enable SharePoint Document Management.

Entity I am using

I used the Case entity for enabling SharePoint Document management. This was shown in my vlog and will be used for screenshots in this blog post.

Step 1

Enable the document management for the Case entity in the entity configuration record either by opening up solutions from within Dynamics 365 or PowerApps (through https://web.powerapps.com).


Step 2

Enable entity in Document Management Settings. There will be a wizard you follow.


Step 3

Enable SharePoint Integration through Portal Details. Head over to the Dynamics 365 Admin Centre and in the Application tab, select your Portals instance to open up Portal Details.

In here you'll see a new option called "Set Up SharePoint Integration." 


Click on this and you'll see an Enable SharePoint Integration option.


You'll be prompted to select your user account to enable required permissions.


Accept the required permissions presented.


Step 4

Configure the entity form to display a sub-grid of Document Locations in the Case entity configuration record either by opening up solutions from within Dynamics 365 or PowerApps (through https://web.powerapps.com).

  1. Make sure you configure the correct entity form that your Dynamics 365 for Portals references.
  2. Make sure you select Active Document Locations as the view as by default My Active Document Locations will be selected.

Step 5

The final step is to create a Child Entity Permission record. The Dynamics 365 for Portals entity form will need to have the "Enable entity permissions" checkbox enabled so that the Portals user can upload files though the sub-grid

There will be a Parent Entity Permission that will drive access to the Case entity. In my scenario, it is an entity permission that allows contacts to create, view, edit and delete Cases if they are the customer in the Customer field of the Case. Against this entity permission, I create a child entity permission.


SharePoint Document Management in action

After the above steps, you're now able to see it in action. 

Sign into your Portals instance and create a new case. After the case is created, you'll now be able to upload files. Remember, Dynamics 365 for Portals respects Dynamics 365 functionality so you cannot interact with a sub-grid until the records is created and saved.

By the sub-grid you'll see two buttons, 
  1. Add files which will allow you to upload files
  2. New folder which will allow you to create a new folder to upload files into
Awesome sauce, you're all set to upload files now 🙂


Once uploaded you can also browse to the SharePoint document location from the Case record.


As demonstrated in my vlog, files portals users delete if they have the permission to do so, will also be deleted in Dynamics 365 and in SharePoint online.

Summary

The most requested feature for Dynamics 365 for Portals returns and is all configurable. I am not a SharePoint configuration expert in the context of Dynamics 365 so if you have questions, it's better suited for the Dynamics Community forum. Please also refer to https://docs.microsoft.com for more information on managing SharePoint documents.

Stay tuned for my next blog post on Dynamics 365 for Portals October Release 2018.

Shout out to the Dynamics 365 for Portals product team for inviting me to play with these features in advance 😁 #thankyou