So, this time we are having a look on triggers and how to move them between Customer Insights Journeys environment using solutions. This way we can have an application lifecycle management (ALM) process for triggers. In the first part of the article, we will dive a little bit into the theory of ALM and solutions. In the second part, I have a step-by-step guide for you on how to add triggers to solutions to easily transfer them. For journeys, emails, or templates there is no ALM support yet, but at least it’s on the roadmap. Stay patient!
By the way: Sorry, if you have that catchy ‘I like to move it’ song in your head now. As you might have noticed from “Trigger me softly” I like music and I often have a suitable song for every situation in mind. Let’s see how long I can keep this up for my articles from now on.
What is ALM?
Let’s quickly have a theoretical look at Application Lifecycle Management (ALM) and why it is important, also for Customer Insights. ALM is a process that oversees the entire lifespan of an application, from its creation to its eventual retirement. The lifecycle involves several distinct phases. Beginning with meticulous planning to define goals and milestones, the process progresses to actual development, followed by building, testing, and deployment. Once deployed, the application operates in a production environment, requiring monitoring, maintenance, and support. Throughout this cycle, continuous monitoring provides insights and opportunities for learning from user feedback and behavior. Of course, you can do all this with the Power Platform. To leverage the full range of ALM features and tools with the Power Platform, all participating environments must include a Dataverse database.
Key concepts for ALM with Power Platform include:
-
- Solutions: These are the primary methods for implementing ALM, allowing you to distribute components across environments via export and import. Components include tables, columns, apps, Power Automate flows, chatbots, charts, and plug-ins.
-
- Dataverse: This serves as the storage for all artifacts, including solutions and in-product deployment pipelines.
-
- Source Control: This should be the definitive source for storing and collaborating on your components.
-
- CI/CD Platforms: Tools like Azure DevOps enable automation of your build, test, and deployment pipelines, and can be integrated with in-product pipelines.
In the context of Dynamics 365, you probably (or hopefully) use multiple environments to support different stages of your ALM process. For instance, you have a development environment for creating and testing new features, a staging environment for pre-production testing, and a production environment for the final application deployment. Using multiple environments allows you to maintain separate configurations, isolate changes, and avoid potential conflicts that could impact your system’s stability.
Solution Structure in Customer Insights Journeys
A solution in Power Platform is a container that holds a set of components, such as entities, fields, dashboards, flows, and more. It’s like a bundle that allows you to manage and transport your customizations. The purpose of solutions is to manage the customizations effectively and only with solutions you are able to move your customizations from one environment to another. Also, solutions allow you to track changes and maintain different versions of your customizations. Solutions are essential for consistency. There are a lot of things to consider when deciding on a solution strategy:
-
- Modularity: Break down your customizations into smaller solutions. There is horizontal splitting which refers to creating solutions that only contain components of the same type, e.g. a solution only for processes and one only for security roles. The other option is vertical solution layering. Vertical layering groups components into functional areas. Often, you will have a shared base/common solution with separate solutions for each key business area. Then you would create a solution for functionalities that the departments share and separate solutions for department specifics.
-
- Managed vs. Unmanaged: Choose whether your solution will be managed (locked) or unmanaged (editable). Mostly use an unmanaged solution on the development environment and from there deploy the solutions as managed to the following environments.
-
- Dependencies: Understand dependencies between components (e.g., an app depends on entities and flows).
-
- Solution Layers: Solutions can be layered (base, dependent, patch) to manage dependencies.
This of course is just a very, very high-level overview of solutions. Having a well-thought-out solution concept is critical to the project’s success in my opinion. That’s why a solution architect plans this as one of the first things before actually starting the development. Redesigning a solution at a later point is quite tricky and not a really nice job.
Move triggers in Customer Insights Journeys
Now let’s come the to practical part of how to move triggers. For effective ALM support, Dynamics 365 features need to be “Solution-Aware,” meaning you model entities as solution components with dependencies recognized by Dataverse. This setup helps resolve dependencies during the import process, ensuring a smooth transition of configurations and reducing the likelihood of errors. To move my triggers from one to the other environment we need to do the following steps:
Access Power Platform Solutions: Open the maker portal (make.powerapps.com) for your current source environment.
Create a New Solution: Navigate to the Solutions section on the left pane and select + New Solution. Give your solution a unique name that reflects the triggers it contains and select a publisher. It is advised to always use the same publisher within the environment. I prefer horizontal splitting for solutions here. This means having its own solution only for triggers
Add Triggers to the Solution:
-
- Click on Add existing dropdown on the top pane.
-
- Select More > Other > Triggers.
-
- Search for the relevant triggers and add them to your solution. The components added will depend on the trigger’s state:
-
- Draft: Trigger record, CustomerAPI record, and CatalogAssignment record.
-
- Published: Trigger record, CustomAPI record, CatalogAssignment record, and customAPIrequestparameter records.
-
- Search for the relevant triggers and add them to your solution. The components added will depend on the trigger’s state:
Export the Solution:
-
- Select Export Solution
-
- Ensure the solution is exported as Managed.
-
- Download the managed solution once it’s ready. (Of course you can also build a pipeline that transfers the solution automatically, but that would
Import the Solution to the Destination Environment:
-
- Navigate to the destination environment and access the Solutions page.
-
- Select Import Solution and upload the managed solution downloaded from the source environment.
-
- Verify that the triggers have been imported and retain their original state (draft, published, or stopped).
Handling Solution Upgrades
When upgrading solutions that contain managed triggers, the process differs slightly from the initial migration. Upgrades will only alter the state of triggers if they are in a draft state in the destination environment. Here’s how state transitions occur during solution upgrades:
-
- Published: The state remains published, irrespective of the source trigger state.
-
- Draft: The state changes to match the trigger state from the upgraded solution.
-
- Stopped: The state remains stopped, irrespective of the source trigger state.
When triggers are imported into the destination environment in a published state, they undergo a publishing process. This process happens sequentially, with a few triggers being processed at a time. During this period, triggers awaiting publication may initially display as being in a “draft” state. However, they will eventually transition to a “publishing” state and finally to a “published/Ready to Use” state. If triggers remain in a “draft” state for an extended period, it could indicate a potential issue. Here are two possible courses of action:
-
- Self-Serve Solution: If you notice that imported “published” triggers are lingering in a “draft” state for too long, consider performing a solution upgrade and reimporting the triggers. This can help circumvent any potential issues during the migration process.
-
- Reach Out for Assistance: If the problem persists or seems complex, don’t hesitate to reach out to the Microsoft support.
One more thing: Assigning triggers to new owners
It is possible to assign triggers to new owners. This might be needed when the original creator of the trigger leaves the company. I was able to change the owner by using the ‘old’ Advanced Search, whether it’s for an unused trigger or one that’s used in a live journey. It’s important that the new user has the correct security role though. Otherwise, I must admit, I am not 100% sure if there could be any other effects. If you know, please let me know 🙂
Conclusion
ALM is a continuous process of ongoing improvement. Managing multiple environments in Dynamics 365 Customer Insights is a challenging but essential task to ensure the reliability and stability of the system. By using Power Platform solutions for trigger migration, you can maintain a robust and error-free ALM process. Utilize these approaches to gain better control, reduce potential conflicts, and ensure a seamless user experience across all phases of your Dynamics 365 environment. If additional components of Customer Insights can also be managed and migrated within solutions, it will become even easier in the future.
References: Solutions – Training | Microsoft Learn, Move triggers between environments – ALM process for triggers – Dynamics 365 Customer Insights | Microsoft Learn
***Please be aware: The content is accurate at the time of creation. It may be that Microsoft has made changes in the meantime.***
Check out the FAQ section of my blog as well: Short questions with quick answers! Go to FAQs
