If you are dealing with the Power Platform from an admin perspective, you must have heard of Managed Environments. It might be a dutch thing, but when talking about this type of environment, license requirements are the first thing mentioned. This sure is something to bring to the equation if you should use it or not, just like the added value of the premium capabilities Managed Environments bring.
In the coming few challenges we will deep-dive into some of those capabilities so that we can make better decisions when developing an environment strategy. With or without Managed environments. The first in this series will focus on Catalog.
Challenge Objectives
🎯 Learn about Catalog
🎯 Know how to administer and use the Catalog
🎯 Create assets to be added to the Catalog
Introduction
What is Catalog?
A big aspect of low-code is the democratization of solution development. The fact that any employee can build value adding solutions also comes with it's challenges. Especially with Canvas Apps the question rises if some sort of template can be created with company branding as the default.
Some companies will adopt the CoE Starter Kit and use the suggested Power Platform Makers group for sharing Power Platform artifacts, but this is not as common as we might want. This also required makers to be able to import these assets into their environment, which adds complexity for the maker. I think that's the reason why you don't see this as a common practice.
Catalog is an answer for this need. It's a central location where Power Platform artifacts are stored, maintained, and shared. It's a great enabler of fusion development, where Citizen Developers, Pro Developers and admins all work together.
Power Platform Catalog is a package that can be installed to one of your environments, that included the Power Platform Catalog Manager app. It's recommended this is in an environment all your makers have access to.
Although the documentation states four personas that will use the Catalog, the solution has three security roles:
Role | Description |
Catalog Submitter | This persona creates artifacts and can submit these to Catalog. |
Catalog Approver | This persona can approve Submissions from Catalog Submitter, and approve requests from the Catalog Consumer. |
Catalog Consumer | This persona can see the Catalog items and install them to their own environment. |
We will experience each persona perspective in this challenge in the order of the table above. This will give a clear view of what it is and how to use it. But first, we need the Catalog to be installed.
Catalog
Installation
Installation is very straight-forward. Follow the instructions on this Microsoft Learn page. It might take a few minutes to finish.
Catalog Submitter
To submit something to Catalog, we must use the PAC CLI. The documentation shows multiple options how you can install the PAC CLI. Personally, I use the Power Platform Tools for Visual Studio Code, that comes with the PAC CLI.
The PAC CLI has several commands for catalog, conveniently grouped under pac catalog. To see commands and it's attributes, you can obviously read through the documentation, but I like to do this directly from the terminal. the PAC CLI is pretty nicely structured. At every level you can just add help to your command to get an overview of what is possible. if you run pac help, you will see all the PAC CLI command groups. if you type pac catalog help, the commands available for catalog will be listed. with pac catalog submit help you will see four attributes, path, package-zip, solution-zip, and poll-status. path is required. the attributed between squared brackets [ ] are optional.
There is a package option and a solution option. Packages are the things that are available from AppSource. If you have installed the Creator Kit through AppSource, you probably have noticed that installing one package will result in multiple installed solutions. I will focus on adding solutions to Catalog, but know that it is possible to work with packages.
The Creator Kit also started as a single solution and later became a package. At that moment the solutions were split into a Model-driven, Canvas, and core solution. Probably for maintainability. You could do the exact same thing.
Let's create a solution. We will keep it simple, as we only want to demonstrate the Catalog process. Create a Developer environment if you don't ave one yet. Create a solution called Challenge 025. Add a Canvas app and add a single button to the screen. Save and publish it.
Now we need to get the solution zip. we can do that fairly easily with the PAC CLI. Add a new folder to your desktop where we will save all the files. I named my folder Challenge_025. In Visual Studio Code, go to File and select Open Folder... and select the Challenge_025 folder you just created.
Open the Power Platform Tools extension in Visual Studio Code. Open a new terminal and run the command pac auth create. Log in with your developer account. An authentication profile is required in order to run commands. The Power Platform Tools allow you to store multiple profiles and browse through your environments and solutions quickly.
Open the Environments & Solutions section in Power Platform Tools and select the environment where you just created a solution. You can do that by simply clicking the star when you hover over an environment. Search for your solution, right-click it and select Copy Unique Name.
Now, run the pac solution export --name Challenge025 command. If you have another name of your solution, change it accordingly. Note that you will get the solution zip in your folder.
Besides a solution or package zip, we need to add a submission document. Run the pac catalog create-submission command to add a sample file to your folder. You need to update the sample JSON. According to the documentation, the following items must be updated.
publisherDetails
The publisher is a little confusing. We need to select a publisher for the solution we create, but the publisher for Catalog has nothing to do with the solution publisher. The Catalog publisher is just a record in the Catalog Publisher table, that is part of the Catalog solution. Multiple Catalog Publishers can be created. This will come in handy when we want to auto-approve certain groups in our organization. We will get to that later.
For now it is good to know that the Publisher ID is the ID of the record. We don't have one yet, so we can remove this property.
Set the publisherDisplayName to Submitter group 1. This will create a new Catalog Publisher with that name.
Optional: We should also set the publisherUpnList to add our own profile to the Publisher Users list. This
catalogItemDefinition
This attribute will give the name to your Catalog item. There are a few mandatory fields here.
id
Although the ID shows a GUID in the sample, it can actually be a regular string. Think of it like the Solution Unique Name. I set it to Challenge025.
displayName
The display name is also mandatory. just make it user friendly. Challenge 025 in my case.
offer/engineeringName
This is a mandatory property so that it's always clear who created the Catalog item. Very nice this is mandatory. Enter your own personal data.
offer/supportName
This field will indicate who to contact for support. Very well thought through. Ideally, you want first-line support for these things. As this is just for demo purposes, enter your own personal data here too. My submission.json file has the content shown below.
{
"modelVersion": "1.0.0.0",
"sourcePortal": 526430005,
"operation": "CreateOrUpdate",
"businessJustification": "Test for challenge 025",
"publisherDetails": {
"publisherDisplayName": "Submitter group 1",
"publisherUpnList": [
{
"action": "Add",
"upn": "miguel.verweij@powerbouwer.onmicrosoft.com"
}
]
},
"catalogItemDefinition": {
"id": "Challenge025",
"displayName": "Challenge 025",
"offer": {
"engineeringName": {
"firstName": "Miguel",
"lastName": "Verweij",
"email": "miguel.verweij@powerbouwer.onmicrosoft.com",
"phoneNumber": "06-12345678"
},
"supportName": {
"firstName": "Miguel",
"lastName": "Verweij",
"email": "miguel.verweij@powerbouwer.onmicrosoft.com",
"phoneNumber": "06-12345678"
}
}
}
}You should now be able to submit your solution with the pac catalog submit --path submission.json --solution-zip Challenge025.zip command,
Once the command finished, you should be able to see it Power Platform Catalog Manager app. We will now switch to the Catalog Approver persona.
Catalog Approver
The Catalog Approver is the person who will manage the Catalog. This is done through the Power Platform Catalog Manager application. By default, each solution must be approved before it can be used. If you run the pac catalog list command, you will get a list of the published items on your catalog. Because no item is approved, no item will be listed. Approving can be done on two levels, Catalog and Publisher.
For the Catalog level, you can enable Global Auto Approval under Settings area, Catalog, Catalog Configuration. As the name describes, this will auto-approve every submission to the Catalog.
A less anarchy option is the Publisher level. Imagine this is ideal if you have multiple development teams in your organization that all are Catalog Submitters, but have different skill levels. For the really skilled groups could decide to allow auto-approval for them. This is done under Catalog area, Catalog Publishers.
Let's start with the default, no auto-approval on any level, all manual approvals. The easiest way to do this is to navigate to the Dashboards page. Here you will see the New Approval Request panel. If you open the Approval Request you created earlier, you can see the Complete Approval and Reject Request options in the command bar. Select the Complete Approval button. Notice that the Approval Request is set to Inactive with the Status Reason Completed.
If you run the pac catalog list command again in the terminal (within Visual Studio Code) it is now listed. Pretty sweet.
Now, let's try it with Allow Auto-approval for the Catalog Publisher enabled. I tried it myself after deleting the Catalog Item. According to the documentation, this should just auto-approve. I asked the product team about it, and they responded it's a two-stage lock. This means the Publisher should be allowed to auto-approve. Their first submission should still be approved. After that, you can select Auto-approval on the item level. After that the Publisher is able to submit new versions of this item, and have it auto-approved.
The Catalog level does exactly what you expect from it. Try it yourself by enabling the setting at Catalog level.
We only just approved submissions. What I really like it the fact that there are additional status fields available for the actual approval process. Under the Approval Process Info section of the Approval Requests you can see these fields. This will truly help the moderators or Catalog Approvers to make sure only compliant artifacts will be available to the Catalog Consumers, and administer it as such.
We have gone through the approval process. Let's see how we can now start re-using these lovely artifacts.
Catalog Consumer
The Catalog Consumer is the persona who wants to re-use the published artifacts. At this moment, it is only possible to get the artifacts out using the PAC CLI. That is a missed opportunity that I will explain in the My findings section. We will continue to just get the artifact out again.
We need to use the pac catalog install command. run pac catalog install help to see which attributes are required. These are catalog-item-id (alias: -cid) and target-url (alias: -tu). The catalog-item-id can be retrieved by running the pac catalog list command. The target-url can be retrieved by right-clicking the environment you want to install it to from the Environments & Solutions section. You command should look like the snippet below.
pac catalog install -cid Challenge025 -tu https://[YOURORG].crm.dynamics.comAll the deployments to target environments can be monitored from the Power Platform Catalog Manager application under Install History.
Once the records shows it's completed, it should be available in the environment you specified as target environment.
My findings
A Catalog feature is a must if we want fusion development to become a reality in our organizations. The submission and approval capabilities are really thought through. The auto-approval for global or Publisher level (assuming the bug will be fixed) and the additional fields for code reviews, security reviews, etc. My current client will definitely like this. The granularity could be increased by allowing single Catalog Items to allow auto-approval. This way you can add exceptions when needed. Exceptions are a standard as weird as it might sound.
I do think that getting artifacts out as a Catalog Consumer requires too much skills to make it a big hit. Many Citizen Developers will not know how to work with the CLI. These early developers are especially the ones who will benefit from a broad set of prebuilt and moderated artifacts. Pro devs usually already have some form of code sharing practice in place, like a GitHub, Azure DevOps, or Jira repo.
If a dedicated Catalog Consumer app will be added where the Consumer can browse artifacts and directly deploy it to their solution from the UI, it will lift up the Catalog as a whole. Again, this feedback is already given to the Product Team. If it's just aimed at pro devs,
Additional Information
Catalog is a feature of Managed Environments. Some might argue it has to do with selling licenses. That might be true, but the fact that deploying an artifact to your target environment requires some sort of virtual machine, makes it sounds logical it's only available for Managed Environments.
There is not a lot of information out for the Catalog. If you have feedback or questions for the team, they use the Discussions functionality from GitHub. A great way to stay informed and connected.
Key Takeaways
👉🏻 Catalog is a central location to store and moderate Power Platform artifacts
👉🏻 The different personas are really thought through
👉🏻 A corporate approval process can easily be plotted to this solution
👉🏻 It is not really Citizen Developer friendly. Yet😏