Home

  • Creating a Real-Time Workflow in Dataverse for Validation

    So, this is a bit of an oldie, but still very useful to know in my opinion. I think that, with all the new people joining the Power Platform in the last few years and with Power Automate being the main “weapon of choice” for anything Workflow related, the good ol’ Workflow Engine might not be as wildly know or used anymore.

    Don’t get me wrong, Power Automate brings massive improvements when it comes to Workflows, but there are a few use cases where a Real Time Workflow that executes within the Dataverse message transaction can be quite useful.

    For example, if you have a validation that you want to use and display an error message to the end user and want that to run server side, so that even if the request is done through the API the validation runs.

    “Why not use a Business Rule with Context set to Entity?” I can hear you ask already (and with good reason). While Business Rules work for traditional fields, for Lookups that won’t be possible. Plus if you have the need to have a custom validation that requires you write some code this is the way to go.

    So I’ll leave here how to create a quick Real Time Workflow that validates a Lookup field and if it doesn’t have the expected value you show the end user an error.

    Create a Real-time Workflow

    To create a real-time workflow in Dataverse, follow these steps:

    From the maker portal, navigate into your solution and click New – Automation – Process – Workflow.

    In the New Workflow window, enter a name for the workflow and make sure you untick the “Run workflow in the background” option. Hit create. Here’s what that looks like:

    This will create the workflow and open up the classic editor in a new tab. This is where you’ll add your logic.

    In this example we’ll just do a quick validation on the related contact record when the contact lookup is populated on the Account, and throw an error if that condition is true.

    To do that, first set the trigger condition, in our case it’ll be create or update of the Contact Lookup field:

    Next, we need our conditions. Select Add Step and “Check Condition”. We’ll then set the condition to be what we want it to be. Let’s say we want to force a contact with an email to be select:

    If this is true then Successfully terminate the Workflow.

    If not then Cancel the workflow and send a message to the user:

    This is what our final Workflow should look like:

    All that’s left to do is to Save and Activate the Workflow.

    From now one, if you try to create a new Account the workflow will run and prevent you from doing it if the conditions aren’t met. Because it’s server side it doesn’t matter if it’s from the form or from the API:

    , ,
    , ,

  • Auto Filter Drop Down filters on Entity Lists

    Recently came across a requirement to automatically filter an Entity List when a filter is selected.

    This was a List where all the filters are drop down boxes so it didn’t feel intuitive to choose an option and then have to click “Apply” for the Entity List to display the filtered results.

    This is relatively straightforward and you just need to find the elements within the page and add an event to the on change of the dropdowns.

    If you have a look at the source for the filters you’ll notice they’re numbered in a structured way with “dropdown_X” where X is the filter position:

    So that’s easy enough, next we need to find a way to identify the button so we can trigger the click event. Again, just have a look at the source code:

    No id but it does use a very identifiable class, “btn-entitylist-filter-submit”, so we can use that.

    All that’s left is to create the code that iterates through all the filters and adds an event whenever an option is selected:

    $(document).ready(function() {
  if($("div button.btn.btn-default.btn-entitylist-filter-submit").length > 0)
  {
    $("div button.btn.btn-default.btn-entitylist-filter-submit").hide();
    for(var i = 0; i < 10; i++)
    {
      if($("#dropdown_" + i).length > 0)
          $("#dropdown_" + i).on('change', function() {$("button.btn-entitylist-filter-submit").click() });
    }
  }
});

    The above code first confirms that it can find a button with the same classes we identified before, if it does it loops a maximum of 10 times and sets a change event on the dropdown to trigger the click event of the button.

    At the same time it also hides the button since we won’t be needing it anymore.

    I’m limiting the amount of dropdowns to 10 but if for some reason you have more than 10 just change the for max loops from 10 to a higher number.

    That’s it!

    ,
    ,

  • How to dynamically set a Power BI Report URL on Power Pages

    I’ve recently had to work with an embedded Power BI report on Power Pages (previously Power Portals), this is a report that has a few different sections that needs to be displayed depending on the page we’re in. Nothing too complicated.

    What I did want to find out was how could I easily configure the Power BI Report in a dynamic way. This is for a couple of reasons, first, this application will eventually be deployed to a different environment, I don’t want to have to manually change URLs everywhere I’ve used the Power BI report. Even if I use a CICD pipeline I still have to add a few tasks to search for the URL string everywhere and replace it with the destination environment URL.

    Which leads me to the second reason, I’ve started using the Power Platform CLI for Power Pages deployments and I want to use a deployment profile to manage the different settings and configurations between environments.

    The solution? A mix of content snippets and a few well-placed liquid tags.

    Configuring the Content Snippet

    This is a simple one. Our end result needs to be a Power BI liquid tag, something that looks like this:

    {% powerbi authentication_type:"powerbiembedded" path:https://app.powerbi.com/groups/00000000-1234-5678-0000-000000000001/reports/00000000-0000-9876-5432-000000000002/ReportSectionf000d000f0000d0000f0 %}

    So we need to store the changing part or the URL on a content snippet. To do this just go into the content snippets and create a new one. Save it as Text and store the URL up to the ReportSection part. It should look like this:

    Build URL using Liquid

    Liquid can be a pain sometimes, especially if you can’t find the tags to do what you need to do.

    The one we’re going to need to build our Report URL is the capture. This tag captures the content of its block and stores it in a variable.

    So, for our scenario we’ll just capture the content snippet created above and any other Report Sections we want to display within that page, and store it in a variable called pbi_path. Then we’ll use that variable as the path for our Power BI Report.

    This should look something like this:

    <div>     {% capture pbi_path %}{{ snippets["Power BI Report URL"] }}ReportSectionf000d000f0000d0000f0 {% endcapture %}
{% powerbi authentication_type:"powerbiembedded" path:pbi_path %}
</div>

    That’s it. If you have any other Power BI reports just create another content snippet to ensure you have a single place where you can update its URL.

    What about deploying to other environments?

    Right, we now have a single place where we store our Power BI Report URL, but do I still have to go into my destination environment and update the content snippet every time I do a release? Nope!

    If you are using the Power Platform CLI you can (and should!) take advantage of the deployment profiles when deploying your Power Pages application between multiple environments.

    You can find more detail on deployment profiles here, but to keep it simple, on your VS Code project create a new folder called “deployment-profiles” and within it create two yaml files, one per environment, called “dev.deployment.yml” and “prod.deployment.yml”.

    Within these we’ll define the records that we want to change per environment, in our case this is our “Power BI Report URL” content snippet. So open the dev.deployment.yml file and add the following:

    adx_contentsnippet:
    - adx_contentsnippetid: 11111111-2222-3333-4444-555555555555 # Power BI Report
      adx_name: Power BI Report URL
      adx_value:  https://app.powerbi.com/groups/00000000-1234-5678-0000-000000000001/reports/00000000-0000-9876-5432-000000000002/

    Note that you have to find your own adx_contentsnippetid that corresponds to the Power BI Report URL.

    Then open your prod.deployment.yml and add the same thing but change the value to be the URL of the Production Power BI Report.

    adx_contentsnippet:
    - adx_contentsnippetid: 11111111-2222-3333-4444-555555555555 # Power BI Report
      adx_name: Power BI Report URL
      adx_value:  https://app.powerbi.com/groups/11111111-2468-0000-0000-000000000001/reports/22222222-0000-9876-0000-123000321000/

    That’s it! Just use the upload command while referencing the correct environment and you’re done!

    pac paportal upload --path "C:\portals\starter-portal" --deploymentProfile prod
    ,
    , , ,

  • Getting started

    Like many, I’ve always wondered about starting my own blog. I’ve been on the industry for quite a few years and always felt like I should start one so that I could give back to the community the same way I’ve received a lot from it.

    So this is it, I’m finally giving it a go.

    I’m not going to say this is something that comes natural to me, but I have no doubt this is something I definitely want to do. So bear with me as I learn how to share some of my knowledge and maybe help some of you along the way.