You are currently viewing Power Pipelines and Enhanced ALM Part 8a – Solution Watcher

Power Pipelines and Enhanced ALM Part 8a – Solution Watcher

With the solution register in place, we still face the risk of people (with the correct permissions) importing solutions that are not being tracked. This could be everything from PCF controls to solutions from developer/sandbox environments. This does not mean there is something nefarious happening, but to be a good steward of governance we need to monitor what solutions are being installed.

Diagram

This diagram is the core of what is going to be happening with the project. In the next post we will break it down further.

Create new table for current PPM

The first step is to create a new Dataverse table that will be used to store approved solutions. It will consist of the following

  • Solution ID
  • Name (string)
  • If the solution is tracked (boolean)
  • Environment Name (String)
  • Environment ID (string)
  • Purpose (text area)
  • ALM Solution (boolean)
  • Who created the solution (email)
  • When it was created (date time)
  • Who approved the solution (email)
  • When it was approved (date time)

The Environment Name and ID will only be used if the solution is added manually to an Environment.

View

The main view will be as follows

Form

The Main form will be as follows. Each of the fields will be set to read only. This is being done because at no time should people be adding or updating the data in the form itself.

Business Rules

Since the Environment ID and Name will not be used if the solution is apart of the ALM pipeline, we will want to hide them. The easiest way to do this is to create a business rule.

The properties of the first condition will be if ALM solution is Yes

Then components to set the visibility to No for the Environment ID, the Environment Name, Solution Created By, Solution Created on, Solution Approved by, and Solution Approved on.

Security Role Updates

For both security roles (Admin and Developers), we will set the Tracking's table to Read Only. Updates will be coming via the Power Automate flows. The Form view is simply to see what is going on.

Ribbon Updates

In addition to the security role updates, we will remove the Add button from the ribbon of the Tracking's table.

Update current flows

1.1 Flow

The 1.1 flow needs to be updated to add the row to the tracking table if it is coming via the pipeline. We will use the same output of the solution name as seen in LINK, mark the solution as tracked and set the purpose to, “From Pipeline”, then set the ALM Solution to Yes.

Update MDA

Within the PPPM MDA, we will add the table to the Backend area.

Update Project Table

The last portion to update will be the project table. We will create a relationship between the watcher table and the Projects table.

Relationships

Form

Within the Main form of the Projects table, we will add the subgrid of the Solutions Watcher Table

With all these updates in order, we can push them all to Production to update the orchestrator flow.

Updating the orchestrator flow

This should be done after all other updates are in production and watcher table has been updated.

First, we need to search against the new solutions tracking table

Then, we need to look up the associated project

Finally, update the get customer and lead info with the proper values

The pipeline will now be able to run as it did before with the updated table

Building Watcher Solution

Since the purpose of this solution is to live in each of our Environments as a managed solution, we can not add this to our current solution or build it in our current Environment. We will need to build the solution in a separate development environment then export it as a managed solution.

In our personal dev Environment, we will create a solution called Solution Watcher and Environment Variable called Production Environment then create a flow called SW - 1.1 - When a new solution is created in the Environment

The SW - 1.1 - When a new solution is created in the Environment it will be built as follows

The trigger will be when a solution is added to the environment solutions table.

The first step is to filter out if the solution is coming in via Microsoft as part a built in feature. To do this, find the GUID of the user “SYSTEM” in the user table. If that matches the user that created the solution, we will terminate the flow.

Using a FetchXML to find the user “SYSTEM”

<fetch top="1">
  <entity name="systemuser">
    <filter>
      <condition attribute="fullname" operator="eq" value="SYSTEM" />
    </filter>
  </entity>
</fetch>

If the created by equals the “SYSTEM” user then we will stop the flow

outputs('List_rows_-_Users_Table')?['body/value']?[0]?['systemuserid']

Now, we will look up who created the solution and write it to a compose

Then, to get the current Environments Name and ID, we will need to run the workflow() expression (Reference guide for expression functions - Azure Logic Apps | Microsoft Learn), then parse the JSON of the output, use the Power Apps for Makers Environments Action then filter it by the output of the workflow().

Next, we will list all rows in the Solutions tracking table in the Production Environment and filter it based on the Name

We will now add a condition that if no record is found, it will add a row to the Tracking table in Production

length(outputs('List_rows_from_selected_environment_-_Tracking_Table')?['body/value'])

If it does not match, we need to add it to the production table Solutions Tracking

Closeout

We will end here at the risk of exercising too much new information. In the next post, we will go over how to install the solutions and the actions that happens when a solution is added.

Leave a Reply