Tag: alm

Exam AB-410: Intelligent Applications Builder Associate

Time for another exam post (I’ll actually be doing 2 posts around new exams this week), this time around building ‘AI Applications’. This is another one of the new ‘AB series’ of exams, which are replacing the older ‘PL series’ of exams. This exam specifically replaces the PL-200 exam, though there’s no mention of the ‘Functional Consultant’ title any longer.

This time, it’s around building intelligent applications. What struck me in the first instance is that it DOESN’T cover using AI to build applications – there’s nothing in it (well, for me at least) that looked at using Copilot or any other AI capabilities within Power Platform to build out components (whether applications or automations). The exam information does mention using AI, but the exam questions (at least the ones I got) didn’t cover it at all. This does feel a bit strange, given how Microsoft keep going on about using AI for building, but given that Copilot for building canvas apps has been deprecated (as an example), I guess that this is following the same trend.

The official description of the proposed exam candidate is:

As a candidate for this Microsoft Certification, you’re a professional who builds AI-powered solutions in Microsoft Power Platform by using Microsoft Copilot, natural language prompts, and low-code tools. You create apps, data models, and flows that connect to agents, AI models and prompts, and visualizations to enrich these experiences.

In this role, your responsibilities include:

  • Developing Dataverse data models, model-driven apps, and canvas apps.
  • Integrating agents and Copilot features into canvas apps, model-driven apps, and Power Pages sites.
  • Creating cloud flows and business logic.

You collaborate with:

  • Environment and security administrators for policies, roles, identity, and authentication.
  • Governance teams on responsible AI principles, application lifecycle management (ALM), solutions, pipelines, and monitoring.
  • Agent developers, solution architects, and other app builders for business solution building.
  • Business stakeholders to gather requirements, iterate business solutions, and promote user adoption.

The overall information for the exam can be found at Microsoft Certified: Intelligent Applications Builder Associate, and there is an official Learning Path available for it.

There is a LOT of different stuff in this exam, but I like it – it shows the breadth of knowledge (& experience) that’s needed in order to build out what’s needed for applications. Canvas apps were somewhat lightweight (at least for me), but I’m absolutely LOVING the focus & usage on Business Process Flows and Business Rules. Yes they’ve been around for a loooong time, and there’s nothing cool, sexy or new about them, but they’re absolutely essential to the ways of working with data & records!

As I’ve posted before around my exam experiences, it’s not permitted to share any of the exam questions. This is in the rules/acceptance for taking the exam. I’ve therefore put an overview of the sorts of questions that came up during my exam. (Note: exams are composed from question banks, so there could be many things that weren’t included in my exam, but could be included for someone else!). It’s also in beta at the moment, which means that things can obviously change for when it comes out of beta.

I’ve tried to group things as best together as I feel (in my recollection), to make it easier to revise:

  • Environments
    • Environment types
    • When to use different types of environments
  • Dataverse
    • Table relationships
    • Record deletion rules, including how they can affect child records
    • Executing logic on record forms – client side vs server side, what is used for each
    • Executing synchronous behaviour – what this is, what can be used for it
    • Different options for validation logic, how they work, and when to use
    • Adding icons for tables
    • Creating/configuring forms
    • Creating/configuring views
    • Custom pages – what they are, when they should be used
    • Column options – what they are, how/when to use. Covering items such as rollups, formula, autonumbering, etc
  • Business rules
    • What they are, and when to use
    • Different types of actions
    • Business required vs Business recommended
    • Scope options – what each one means, and how they actually work/affect data
  • Approvals
    • What they are
    • How to configure, including different types of approvals
  • Business process flows
    • When to use
    • What the different components are (eg steps, stages etc)
    • How to configure
    • Triggering Power Automate flows
    • Usage of them on existing records vs new records
  • Power Automate
    • Trigger types – differences between them, when to use
    • Handing connections
    • Handling time-outs/retries
    • Handling/configuring Run After behaviour
    • Concurrency – what is it, when to use, how to configure
    • Connecting to AI Builder
    • Conditions – what they are, how/when to use
    • Branching logic – what this is, how/when to use
  • Canvas Apps
    • Triggering record submission and saving
    • Triggering Power Automate flows
    • Configuring properties for buttons (different formula types)
    • PCF controls – what they are, what they’re used for, creating them, reusability
    • Power FX commands – selecting right syntax to be used for code examples, managing retries, managing errors
    • Variable types – what they’re used for, differences between them
    • Collections – what they’re used for, how to use them
    • Optimising data loading – how to do this, what to consider, what to use
  • Integrations
    • Connecting to Microsoft components (inside and outside of Power Platform)
    • Connecting to custom API’s
    • Connecting to external API’s
  • Security
    • Security roles
    • Security teams & access teams
    • Entra ID security groups
    • Giving access to applications
    • Checking user access rights
    • Dataverse record ownership – different types of record ownership, differences between them, how to set up/configure
    • Restricting access to tables, views & forms
    • Hierarchy security – different options available, differences between them and when to use them
  • Auditing
    • Global level
    • Table level
    • Row level
    • Retention settings
    • Change tracking – enabling it, when it should be used
  • Application Lifecycle Management (ALM)
    • What solutions are used for
    • Unmanaged vs managed solutions
    • Exporting & importing solutions between environments
    • Adding components to solutions (new vs existing components, and how to do this)
  • AI
    • Using AI to summarise records – how to set up, configure and use it
    • Using AI Builder – capabilities, how to set it up & use it, how to call it from different component types, how to use outputs
    • How to update AI Builder prompts

I hope that this is helpful for anyone who’s thinking of taking it – good luck, and please do drop a comment below to let me know how you found it!

I’d also be interested in your thoughts/opinions around the direction that Microsoft has taken for this!

Power Platform ALM Changes

As a starter for 10, if you haven’t yet looked into ALM for Power Platform, you should most definitely be doing so! ALM is, of course, Application Lifecycle Management. This is how, in a nutshell, we move solutions between environments.

In the good old days, this was done manually of course (CRM 4.0, I’m looking at you!). Today, though it is of course still possible to export/import solutions manually, it’s not the Microsoft Best Practise method. Doing it manually also means that it’s unlikely that you’ll have appropriate source control for your solutions too, which let’s face it, isn’t the best.

Want to look at a previous solution version? Hmm – do you still have it saved on your machine or not?

So we should generally know why we’d want to use ALM. But which tooling do we actually use for it? Going back to the on-premise days, there was TFS (or Team Foundation Server, to give its full name). This was a full source control respository, allowing developers to check in/check out code, built solutions, deploy them, etc.

With the move to ‘cloud based systems’, the TFS replacement is Azure Dev Ops (or ADO, as it’s usually referred to as). ADO works in essentially the same way as TFS did (some differences, but they’re not really relevant here), but does so through the cloud.

When it comes to Power Platform solutions, ADO uses the ‘Power Platform Build Tools’ capabilities to hook into Dataverse & pick up solutions. The tools essentially gives ADO the ability to connect in to a Power Platform environment, build/export solutions, deploy solutions, etc.

More information on the toolset can be found at Microsoft Power Platform Build Tools for Azure DevOps – Power Platform | Microsoft Docs

Now there are some limitations to the Power Platform Build Tools. In fact, I’d be so bold as to say that currently they’re not in a fully mature state. It’s not possible to do everything that you can manually (well, not with the inbuilt capabilities – there are some ‘hacks’ around that can extend them). At the moment, it’s essentially 1.0.

Well, Microsoft is announcing that they’re now releasing 2.0 of the Power Platform Build Tools this week!

In fact, this is so new that at the time of writing, there’s no Microsoft Docs available for this! So what does version 2.0 bring, and why is Microsoft releasing a new version?

So Microsoft has actually had this in planning for a while. There’s a lot going on with GitHub, as we well know, and Microsoft wants to drive the consistency of the experience for users forwards. At the moment, they work in somewhat different ways, and the aim is to bring this to parity.

The main change that the new version has is that instead of tasks being PowerShell based (which they are currently), now the tasks will be Power Platform CLI based. So Microsoft is changing the underlying working method from PS to CLI. Some of us will, of course, already be familiar with the way that the CLI works, and it’s really nice to see that the capabilities will now be part of ADO.

Now don’t start worrying that your current ADO pipelines (v0) will suddenly stop working. Microsoft is not doing anything with v0 at this point in time (though they may potentially deprecate in the future). So all of your existing ADO pipelines using the Power Platform Build Tools will continue to work, but no new features are going to be being released for it.

In terms of switching to using v2, it’s really quite simple – you’ll need to change the task version type as so:

If you are currently using YAML (as so many wonderful developers do) to author pipelines, you’ll need to do the following in the YAML code:

It’s very important to note that it’s not possible to mix and match task versions. If you do this, the ADO pipeline will fail, so please don’t try this!

I’m really excited about this, and to see that the CLI capabilities are being brought into play for ADO capabilities. I’ll admit that I’m wondering what else will be being released (in the fullness of time), as I’m sure that this is just the start of some great new stuff!

One of the things that I’m REALLY hoping for is the ability to use ADO pipelines to be able to migrate Power App Portals (or Power Pages), as currently it’s only possible to do using the Power Platform CLI, or the Configuration Migration Tool. It would be amazing to be able to do these with ADO pipelines as well!

Canvas Apps & Power Automates

So it’s been a busy few weeks here, which is why I haven’t really been putting up any articles. March/April is always a busy time for our family with stuff going on, and this year I decided not to push myself to get articles out, as otherwise I’d be running very low on sleep!

That being said, I’ve still had some great ideas about things that I’d like to share, and have been keeping a series of short notes for me to pick up. Today’s topic is one of them, which I think has been a major pain to anyone involved in canvas app development!

So, the back story to this is that we’re able to use Power Automate flows together with canvas apps. What I mean by this is that we’re able to directly trigger them from within the canvas app, rather than needing to do something like edit or create a record, and then have the Power Automate flow trigger from the record creation or modification.

There’s a specific Power Apps trigger that’s available within Power Automate exactly for this purpose:

When clicked, it gives us the trigger line in the steps as follows:

So what we’d do is within the canvas app, we would bind a button (or another control) that when selected, it would then go away & trigger the Power Automate flow. Great – so many different things that we can get to happen! One of the benefits of doing things like this is that we can then pass information from the Power Automate flow back to the canvas app directly:

This can then mean that the user can know, within the canvas app itself, that the Power Automate flow has run, and use data (or other things) that have come out of it.

OK – all good so far.

The main issue to date has been with deploying canvas apps together with Power Automate flows. See, as per best practise, we would create a solution, place the canvas app, flows, and anything else that’s necessary for it to work within it, and then deploy the solution to our target environment/s. And that’s where things just…didn’t go quite right.

Obviously within the development environment, the canvas app would be hooked up to the flows, and everything would work. Clicking the button would cause the flow to run, etc. User authentication would be in place (along with licenses of course!), and it was just fine.

But when deploying a solution containing canvas apps and associated flows between environments (regardless of whether it’s been manually deploying, or automated using a tool such as Azure DevOps), the connections to the flows would be broken. Ie, the canvas app would run, but the flows wouldn’t trigger. Looking at the connections in the canvas app within Studio would show something like the following:

All of the connections to Power Automate flows would show as ‘Not connected’. It’s not even possible to click the ellipse next to them and re-connect them – the only option available is to remove it from the canvas app!

So in order to get things working again, we’d need to do the following steps:

  • Open up the canvas app
  • Remove all connections to Power Automate flows
  • Add a temporary button, set it to be a Power Automate trigger
  • Click through all of the Power Automates needing to be connected (waiting for each one to connect, then go to the next one)
  • Remove the temporary button
  • Save and publish the solution

This, in a nutshell, has been a (major) headache. For example, I’ve been working with a solution that has over 30 Power Automate flows that can be triggered from the canvas app (lots of different functionality!). Each deployment has needed the above process to be carried out, which has usually added on at least an hour to the deployment process!

Now, this hasn’t been something that’s been unknown. In fact, the official Microsoft documentation noted the following:

So this is something that Microsoft has been well aware of, but it’s been a pain point that we’ve had to work with.

However, this has now ALL changed, which I (and MANY others) are really pleased about!

Microsoft has rolled out an update last month that means that canvas app connections to Power Automate flows will NOT break when they’re deployed across environments! This is such a massive time-saver, that I’m now trying to work out what to do with all of my free time! Only kidding…more project work will commence!

So what we can now do is take our solution, deploy it across the different environment/s that we need to get it out to (whether manually, or automated using tools such as Azure DevOps), publish the solution, and then everything works! Amazing!!

One small caveat though – to ensure that this work, you will need to go into the app, and re-publish it on the latest Power Apps version. This should of course be done in a development environment, and then can be exported and deployed as required.

Microsoft have also updated their documentation at https://docs.microsoft.com/en-us/powerapps/maker/data-platform/solutions-overview to remove the limitation text shown above. It’s a good place to keep an eye on changes that occur over time too.

This is definitely a welcome piece of development, and I know that we’ve been eagerly waiting for this for a while, and now it’s here!