Power Platform pipelines or Azure DevOps pipelines for ALM? with Benedikt Bergmann

Neil: [00:00:00] Benedikt is leading a deep dive Power Platform ALM live online course for CRM-Konsulterna on the 29th and 30th of August. If you're joining this episode before that date and you're interested in leveling up your ALM skills, check out the links in the show notes to register for Benedikt's course. That address is amazingapps.show/147.

Neil: Hi, I'm Neil Benson from Customery. Welcome to Amazing Apps. I'm here to help you build amazing, agile Dynamics 365 and Power Platform applications your stakeholders will love. Thanks for joining me. 

This is episode 147. If you're listening to the audio podcast, you'll find show notes for this episode at amazingapps.show/147. 

Today's episode is all about ALM, Application Lifecycle Management. Power Platform ALM describes how we deploy and maintain our applications. Healthy ALM is when we have robust governance processes and tools for deploying and maintaining applications in production. In a way that's secure, repeatable and efficient.

ALM used to be hard and was only really practiced by teams of experienced developers building enterprise applications. There's a quote from Nick Doelman later in this episode. Let's hear what Nick has to say about ALM. 

Nick Doelman: There is no project too small to apply ALM, especially in the Power Platform area. We now have lots of tools and features available to us to make this easy, no matter how big or small the project. 

Neil: Even if you're a team of one low code app builder, you should have a repeatable way of securely and efficiently deploying and maintaining your application in production.

Benedikt Bergmann joins me on Amazing Apps today. He's a Power Platform consultant at CRM-Konsulterna in Sweden. You'll find links [00:02:00] to Benedikt's LinkedIn profile, his blog, and his GitHub page in the show notes. 

Benedikt's background is developing custom NET apps. He got into Power Platform apps around 2017, and he's received an MVP award since 2021. Today, he's known for his expertise in application lifecycle management. 

In this episode, Benedikt and I discuss the different ALM options for small teams building simple apps and enterprise teams building mission critical apps. We discuss tools and environments and testing and components that don't fit in solutions and lots more.

Here's Benedikt Bergmann from CRM-Konsulterna. 

I Welcome to Amazing Applications. It's great to have you on the show. Welcome, my friend.

Benedikt: Yeah. Thank you for having me.

Neil: Yeah. 

Benedikt: to be in here.

Neil: It's great to connect with you. I, I'm wondering if you could maybe help us in this topic and we'll talk about the appropriate ALM strategies for different sized projects. I haven't touched the new Power Platform pipelines features yet. I hope I can say that right a few times really quickly.

Power Platform pipelines. And I'm wondering if you've researched that, if you've used them in projects. So let's start with with that and figure out what size of project is ALM good for? 

Benedikt: Yeah. So to, to quote one of our dear friends, Nick Doelman, he once said in a, in a session no project is too small for ALM and I totally agree. So we usually do ALM even if, if it's just one person or I do it in my project when it's only one person, it's only me. Because if you set it up and if you, if you have to do good practices, as you mentioned, and if you have like templates and so on, then it's not that big of a deal setting it up and it will help in the, in the long run time wise and if someone else comes in and takes over and so on. 

Neil: So there's lots of different parts to ALM. If you're on your own doing a single person [00:04:00] project, are you doing everything? You know, are we, are we just talking about moving solutions from one environment to another? And checking the solution into source code. Is there more to it than that when, when it's just you?

Benedikt: Yeah, so we have this internally we have this template it's a YAML file or different YAML files combined to one, but it basically does several stuff if there, there are basically two, two YAML files, one for exporting stuff, and one for deploying or releasing it to the downstream environments.

So the first one is creating our artifacts, which is basically the solution, or if you have any Azure functions around and so on. But this is also running our tests, building the solution and checking whether or not the build is going through for all the plugins and so on. And compiling our front end stuff, the scripts from TypeScript to, JavaScript and deploying the latest version to development and then doing an export.

So it's not just the export and unzip to the source control, it's the other stuff as well. And if the project doesn't have any development, because those projects we have as well where we only do low code stuff, then it's easy to inactivate. It's just like configuration. Yes, no or true false in that case. And then it would just skip the other stuff. 

Neil: Okay. You, you mentioned YAML file, which is enough to strike fear into a lot of people's hearts. What's your experience like working with, with YAML? Does it take a long time to, to get the kind of experience required to maintain this YAML file that your team is using in your template?

Benedikt: Yeah, it took me some while to, to really get it, get it right. And there is still some, we see bugs every now and then and fix it. So it's not the easiest thing YAML, but if you understood it once, then it, you like kind of get a hold of it. But it's easier if you are a developer that's for true for, for sure.

But yeah, I mean, I started with the with the UI pipelines the [00:06:00] normal click and point stuff in DevOps. That's working fine as well. You can't do it as good as templates as you could, would do with YAML files. So the templating is better with YAML files.

Neil: So in terms of sophistication, your team tends to use Azure DevOps with a template with YAML files in it, even on very small projects, but if I'm, maybe I'm not a developer, maybe I'm just an application builder, and I don't have a lot of Azure DevOps pipelines experience tell us about the new Power Platform pipelines.

Are they worth using? Should I try them or should I just bite the bullet and go and learn Azure DevOps?

Benedikt: So we haven't used them in any projects so far because they haven't had all the features we needed. Like they, they weren't able to store an unpacked version of the solution in the source controller and so on. 

Neil: that's the version I remember. Yeah. where's control. 

Benedikt: Yeah, exactly. And that was one of the main things I was missing, or for me was missing.

A few weeks ago, they released a new version where you can have pre and post steps to your deployment. And then you could request Azure DevOps Pipeline from your Power Platform pipeline.

And this one could do stuff you want to have, like anything else, like deploying to an Azure function. Or unpack the solution or extract the solution, unpack it and store it in the source control before it will deploy, it will be deployed to, to test the production.

So now got better. And it basically now is in a, in a state where we could use it for smaller projects. But still it's not as good for templating than it is in plain Azure DevOps or GitHub actions.

Neil: Okay. So, so maybe use Power Platform pipelines if you're a very small team of makers, low code [00:08:00] components where you, it sounds like you still might need a professional developer somewhere in the background to help you calling Azure DevOps to do some of the more sophisticated things. But, you know, that developer could set up the, Azure DevOps components for you once, and then you can build your own and maintain your own Power Platform pipelines.

I've got to be honest with you, Benedikt, from what you've just described, I'd still probably prefer teams learn Azure DevOps. It sounds like they're going to have to, to do that anyway. But we'll see. It's really interesting space to watch, and I really appreciate the team at Microsoft putting the effort in to help low code teams use a mature ALM 

Benedikt: Yeah, I mean, I mean, if you, if you don't have a developer or a pro coder by hand, then those pipelines are good alternative, because then it's most of the time either no ALM at all or manual ALM only or or yeah, that's basically what you have. So now you can go like the step and say, okay, we have some automation But it's not like the whole flagship thing. It's, it's just the, the smaller one, but it's better than nothing. So,

Neil: Okay. And for those smaller projects, how many environments do you normally see teams provision? Is there a recommended number for small projects and for enterprise projects?

Benedikt: yeah, so we usually require three dev, test and production. We have some customers with, where we took over the solution from other vendors and they only have two, like they have test and production. And in that case, it's hard to over convince them to have a third one, even so it's not no additional cost.

So, yeah. But usually we, we at least have, have three. I was in one project where we were like 40 or 50 people in the project and then we had 12 or 13 environments and that, I mean, that, that, [00:10:00] that's was like the normal amount they had in all of the project, not only Dynamics or Power Platform. It was all of their web development.

They all had development, integration development, and Q& A, performance test, and whatever. But for, for the Dynamics implementation, it, it felt a bit too much. So something in between, I would say 3 and 12 is like the, the main goal. 

Neil: my, my team's yeah, three at a minimum, even for the smallest projects. And then most of our enterprise projects tend to be five or six environments. And some of those higher environments are shared environments. So, you know, we're, we're doing maybe a staging environment and that's coupled up to this, the staging version of the legacy system or the staging version of the ERP or the staging version of the you know, the government system or whatever it is we're hooking into.

So it's a, it's a big shared state pre production environment with lots of different applications running in it.

Benedikt: Yeah, what we usually have in addition quite often, or, yeah, sometimes is if the customer wants to do stuff themselves. Then they get a different development environment, 

uh, and then build on top of our solutions. 

Neil: Okay. Talking about the development strategy then, if you've got four or five developers in a team, does each developer have their own environment? Is your development environment, a kind of development integration environment or using a shared, 

Benedikt: Now we use a shared development environment, usually. 

Neil: Okay. Have you seen any benefits in going for every developer having their own environment?

Benedikt: Not in this size. So not if you only have like four or five people doing stuff. If it, if it's getting bigger, if you, what we planning to do in another project we just started which is quite a big implementation as well. We have several teams doing stuff and then every team gets a development environment and then we have a development integration or merged development and then we go further on to UAT and [00:12:00] integration tests and so on.

But all, every team still is like four or five developers. And they share the environment.

Neil: Yeah, I remember working with Microsoft Consulting Services many, many years ago, probably 10 years ago, and this was on prem CRM, probably 2011. And all of their developers had individual development environments. And it was the first time I'd seen that. And they. It was pretty shocking to me at the time because back then environments were really expensive, not just you know another license needed, but you had to have your own hardware essentially.

So yeah, it was, it was a very overkill for the size of project they were working on at that time. But I can imagine that approach being useful, like you said, if you're working in a multi-team development group. 

Benedikt: Yeah. And then if you, if you go that path there's other things to consider like branching strategies of your or your repository and so on. So I know we have like this Power Platform Level Up Discord. Which is for developers. So if there is some developer listening in I will drop you the link.

So please join really great discussions. And there, there was a discussion around exactly that a few weeks ago. And some of those were like, okay, we have it per developer and they, or per feature, and we create automatically the environments in the night or during the night, like 10 or 15, and then they can claim it.

And then they will be like trashed in the night thereafter and stuff, but it's, it's a lot of management. And a lot of pipelines running automatically during the night, deleting environments and so on. So it's, and also the merging of those in branches and so on. It's it's a lot of overhead.

Neil: Yeah, it's, it's, amazing, you know, with the flexibility that we have, lots of teams come up with their own practices. I'm sure if you peeked inside my, what my team does, you'd scratch your head at some of the, some of the things that we get up to, but it feels right for us. You know, it's, it's appropriate. Everybody's used to it. 

And sometimes that's [00:14:00] just these things emerge. They're not designed from on a piece of paper. They just, you know, the practices emerge and suddenly we end up with something that's quite complicated when somebody else looks at it.

Benedikt: Yeah. And it, what would be the template where we have, it's, it's it grew over time as well. So first we started with like the pipeline and it was like, Oh, maybe you want to run our tests there as well. Oh yeah, I will add it. And so on. So there were a lot of iterations for it.

Neil: Yeah, I bet if somebody else took a peek at your team's template, they would scratch their head as well.

Benedikt: I would say so. Yes. Jonas does sometimes when he takes a look at our template I created. Like what is this? Yeah. 

Neil: Tell me a little bit about the running tests inside a pipeline. The tests that you're running, is that just a, a suite of unit tests or are you doing any kind of user interface testing on an automated basis? I'm always curious what kind of tests people can run inside a pipeline.

Benedikt: So we try to create at least unit tests and we sometimes have integration tests. So if you plug in and then integrate to, to Dataverse to some instance and those are the ones we, we run in, in our pipelines that are included there. But we also have a setup for EasyRepro tests, which is end to end front end tests.

I think we have maybe one project where we really use those because usually the customer don't want to pay for us to set them up. So we don't use them as often as I would like to. But those are like unit tests, integration tests, and maybe UI tests, or yeah, we see EasyRepro even so EasyRepro isn't like the recommended thing any longer for Microsoft. They won't develop it further as I heard. So it's more Playwright at the moment.

Neil: Okay. Yeah, I've, I've heard of Playwright. I haven't, I haven't played with it yet. Another, another tool to get my hands on. 

We're, we're having some challenges at the moment with one of our projects where the customer wants some tests run at the end of every [00:16:00] deployment, but they want screenshots to be captured and the screenshots have to end up in a, in a report. The report generator, I can't remember which way around it goes. It can either get executed. In an Azure DevOps build or an Azure DevOps pipeline, but not whichever one it supports is not the one that we, where we want to use it. So yeah, it's a little challenging. I'm sometimes doing some integrated testing. 

I mean, it keeps moving, right? There's always new tools, new, new approaches. We just mentioned Playwright, gotta stay frosty. 

Benedikt: And in the project we once implemented performance tests that were run like in a nightly basis. From a pipeline as well against a specific performance test environment.

Neil: So performance testing is an interesting one because it's a shared data center, right? You're, you're, you're hammering the resources and you're sitting on a scale group in a data center and other customers are on the same scale group, the same set of servers. Do you do any kind of collaboration with Microsoft to say, Hey, we want to do some 

Benedikt: So this was in a FastTrack project. So we were at like a tight discussion with Microsoft about it. And they suggested some times when it would be best to not interrupt all the others. So during the night, basically. So they were aware of it. We had some discussions whether we should do those tests against a sandbox environment or a production environment because the customer wants to test as near as it will be in production.

So they wanted to have it like in a production environment of type production so that it gets the same amount of resources, but Microsoft suggested doing it in sandbox. Because it has less resources and therefore we see peaks in performance earlier. We don't have to do as much requests to see those. So that was quite an interesting discussion there as well.

And then you also, [00:18:00] if you do it in the sandbox, those are the production type and sandbox types are different scale groups. And therefore you don't affect the other production environments of the other customers as much or not at all because they are different servers. 

Neil: Okay. So, so there's an assumption there that sandbox environments are all clustered together on the same scale groups that sandboxes don't share scale group with production. I never thought about that. You're probably right. I would do it that way if I was designing my data center. And there's always a myth that sandbox environments get less resources than production environments.

Sometimes Microsoft say, no, all environments are created equal. In reality, I still suspect that sandbox environments get fewer 

resources than 

Benedikt: Yeah, and that's what they told us a few years ago, maybe it has changed in between, but back then they told us it's less resources. For sandbox

Neil: I 

Benedikt: or, or, maybe, maybe the same amount of resources, but more sandbox environment within one scale group. So they, if, since they share it,

they at 

Neil: density. 

Benedikt: the end get less, so,

Neil: Yeah, I like that idea though. So if I run my performance tests in sandbox and I hit some kind of threshold, now I know the pinch point of my application. Now I know where the bottleneck could be, and I can work to resolve that if I need to. Knowing that, I've got a higher threshold in production, but I've hopefully fixed the underlying issue. That's a good idea. Helps you spot the problem earlier. 

What about penetration testing then? Do you do any kind of pen testing? Because that's even more invasive on other customers in the scale group. One person's penetration test is, you know, somebody else's denial of service attack.

Benedikt: No, we, I have never done penetration tests.

Neil: Okay. I, I've never done them either. My customers have, but they've always engaged a third party to do it, a security consultancy. Maybe they don't. It's a bit hard to do your own penetration testing when you know the code and you know the environment, so it'd be better if somebody else gives it a [00:20:00] crack on it. It's a pretty specialist set of skills as well. 

We're thinking about what can be included in ALM. So there are definitely parts of the Dynamics 365 or Power Platform components stack that are still quite difficult to, you know, include in a solution. I was delighted recently, 

the access teams were finally made solution aware. So now I can include those in my solution. You've mentioned functions, Azure functions a couple of times. So I presume that your, ALM process includes Power Platform solutions, but other components as well, Azure components, how are you handling things that are not solution aware and including Azure components as well?

Benedikt: Yeah, that depends on the, on the component for sure, because so like basically Azure components, they are quite easy to, to handle because they have usually good pipeline support. In Azure DevOps or GitHub Actions for example, Azure Functions, there is there are steps for it, you can just use those.

It's like one or two steps to deploy those. So we have a special YAML template, which we can reuse for every Azure function we have and then it will deploy those. And we also sometimes use BICEPS scripts to, to create resources in Azure DevOps to make sure they all are the same and naming conventions and so on.

And they, those run in the same pipeline as our solution. So when we deploy to test, then we like either first deploy our solutions and then our Azure components or the other way around, depends on what suits us best. But if it comes to to components, the Power Platform, but not solution aware, it's more complicated. So, and then it depends, like you can, some of those you can just move with configuration migration tool from Microsoft, if it's just data basically. But [00:22:00] others are yeah, way more complicated than you need some PowerShell scripts to do stuff.

Yeah, for example, if you want to move the duplicate detection rules, they have to be inactivated before they can be exported. Otherwise they won't follow in the solution. So you should have a script which go through them, deactivates the ones you want to export or have in your solution. So you don't forget to inactivate those and then mess your environment up such stuff which is very messy.

And then there's other stuff where you, where you need different solutions, for example, because usually Microsoft's recommendation is to have one monolith solution. That's what they say. Or the solution separation or segmentation, but then one solution or for every solution you need in a separate environment.

 Because otherwise you could get dependencies and so on. So that's the MS Microsoft recommendation. And then there's stuff which you can't have in the same solution. For example, if you have a custom connector and flows. Using this custom connector, they can't be in the same solution because and I don't know the details under the hood, but they tried to install the flows before the custom connectors, I assume, because it, it 

Neil: probably. Yeah. 

Benedikt: because there's some missing dependencies because the flow wants to have the custom connector, which isn't there because it's in the same solution.

So you have to have a separate solution and install the custom connector first. Same. 

Neil: sounds like that should be an easy fix in the solution importer.

Benedikt: We also had a discussion with some from Microsoft in this discord and they were like, yeah, it's the problem is that they, the custom connectors are hosted in API Management in Azure and they have to deploy it there. And there's some timely stuff that. There's asynchronous and then it's too, too slow or something.

So they, they can't easily fix it, unfortunately. So that's one of [00:24:00] the known limitations. And then as well, like stuff like SLAs and automatic record creation rules. They should be. In their own solution with all the components you need, like the the automatic record creation rules and related flows should be in the same solution otherwise you could get errors. And if anything else is in the solution, you could also get errors. So all this stuff has to be handled as well.

Neil: Yeah. I think that we have such rich and varied applications these days that I'm sure there are very specific lessons learned around Dynamics 365 Marketing and how email templates and customer journeys get migrated. Or if you're working with Power Pages, you the strategy for migrating portals keeps evolving, which is great.

But if you haven't done a portals project or Power Pages project for 12 months, you're going to have to relearn your ALM techniques. You just mentioned lots of great stuff there about like Customer Service and SLAs. I'm sure if you're working with Power BI and you've got reports and charts and dashboards authored in Power BI and you want to move those in the solution, there's different strategies as well.

So there's so much to learn. I was wondering, do you see a pattern where there is a role for a DevOps engineer within a Microsoft partner practice or within a team who's just a specialist in YAML and pipelines and all of these edge cases, and they're the expert that all the teams rely on for how do we get this stuff into production?

Or do you see teams just learning and managing ALM on their own without that central specialist?

Benedikt: No, I see a space for this type of, and I don't have this role, but I would say I have this role in our company. So it's not an official role but basically in every project where we have our pipelines or want to move to our pipelines I will be, be called into more or less. And if there are any troubles in the pipeline failing or so on then [00:26:00] I usually have my colleagues resolving those.

Yeah. So I think. It would be good to have at least one person that really knows all the whereabouts or not all of it. I don't know all of it either, so, but that knows how to navigate in it and how to get the information. If something happens and knows YAML and the usual pitfalls you can, you can have or yeah. And how to fix those.

Neil: Is there a resource somewhere, Benedikt, where I could go and look up, you know, ALM on a Microsoft Learn website or something and say, I'm trying to move automatic case creation rules. What's the ALM approach for those types of records? Is there a resource we can go to and find that information easily?

Benedikt: I don't think so. I, I, I have to admit that the, the documentation on Learn for ALM, they have been getting improved a lot in the last couple of months. But I've never seen like for like those specific cases, it's more like if you look on the page from SLA, for example, then there's like a side note. If you want to move those, they have to be in the same environment or how we learned about it.

It hasn't worked. So we asked Support and they were like, yeah, obviously they have to be in their own solution. So, okay. Yeah. So I don't think there's like this one page where we, we can go, but the, the overall ALM page is improving at the moment. Which is good. 

Neil: Yeah. Yeah. Good. But if I wanted, if I was new to the Power Platform or I was a low code maker and I wanted to build up my Azure DevOps skills, is there a course you'd recommend? Are you going to create a course for us? Or is there somewhere else I can go to learn this stuff? Cause there's, I'm pretty sure there's generic Azure DevOps training available, but I want to learn it specifically for Power [00:28:00] Platform and Dynamics 365 apps. Is there such a training course available?

Benedikt: I actually will give one end of the month two day ALM training course virtual in English. And we are thinking about doing this as a on demand course. Haven't decided that yet. So if there is good enough demand, Then I would have more convincing arguments to invest the time. Yeah, but so I will have, of course, the first one of my ALM course now end of the month and probably do it as an on demand course in the future. 

Neil: Okay. So tell us a bit more about your course. It's, it's two days. Whereabouts is it going to be hosted?

Benedikt: Yeah, it's two, two days on Teams. Hosted on the 29th and 30th of August now from 9 a. m. to 4 p. m. Central Europe summertime, so CST. Stockholm time. And yeah, it's two days of ALM training and covers like all the basics. So the first day is more leveling up. So what is ALM and the basics of Power platform, ALM, like solutions, environments, and difference between Power Platform pipelines GitHub and so on, and also learning YAML, build tools and what is special with environment variables, connector references and hands on lab for sure to test all the learned stuff out.

And then day two is more, more like into, into depth, like how is the project set up, versioning, quality gates. Deploying pull requests and such stuff and deploying data within the pipeline, running tests and all, all like the, the detailed, detailed stuff.

Neil: Yeah, great. Well, we could do a podcast episode on each of those modules, I think. 

Some really interesting stuff there, Benedikt that sounds awesome. So good on you for putting that together. It sounds like it's been a lot of hard work to get to this stage. The one that's coming up at the end of August, is that the first time [00:30:00] you've run it?

Benedikt: Yes. Yeah. It's the first time I run it. Yes.

Neil: I've got on demand training courses. Yours has got some hands on labs for Azure DevOps, which is, which is amazing. I think developers require that when they're learning. Thanks. And that's quite hard to work into an on demand course. So good luck with that. Let me know if I can help. 

Amazing. Benedikt thanks very much for sharing your your ALM experience with us. It sounds like Power Platform Pipelines is still a great place to start if you're a low code maker, learn the basics of the techniques there. There's some shortcomings though, and so they might need to work with a professional developer in their team, and then bigger teams or bigger projects really need to start with Azure DevOps and consider building out some templates to make their ALM processes repeatable across projects and across teams.

We didn't get to touch too much on that, but on the differences or the, the similarities between Azure DevOps and GitHub, maybe save that one for another topic as well. Is there anything else you'd like to share with our audience? I'd love to, if you have a few moments, I'd love to grab you in a retrospective, but is there anything else you'd like to share with our audience on this topic?

Benedikt: Don't be afraid and get started with it. And if you have any questions, just reach out and I'm happy to help.

Neil: Yeah. Good. Okay. Well, Nick Doelman's quote still stands true, "No project is too small for ALM". Benedikt endorses that philosophy. So go for it. 

Oh, Benedikt, if you have a few moments, what I'd like to do is just to get to know our guests a little bit better in a segment I call the retrospective, where we just uncover your background a little bit.

You've been working with Power Platform for six or seven years now, but you started as a NET developer. Is that right?

Benedikt: Yeah, exactly. So, so I'm from, from Germany and moved to Sweden six years ago.

Run 

Neil: I didn't know that. 

Benedikt: Yeah. So back then I was yeah, dotnet and frontend developer. So I did both backend and Florence frontend in some [00:32:00] regards. And it was most Angular, a bit React. Later on and then it was a bit on and off with some Dynamics on premise customers when they needed like a small script or or something like that.

And then I moved to Sweden and they needed someone in a on premise 2011 project. Developer. So I was thrown into that. And after that, I, it stuck. So I stayed at Dynamics and the Power Platform.

Neil: Very cool. Very cool. So, so Sweden is home now.

Benedikt: At the moment it's home, but we will move back to Germany in two years, 2025. 

Neil: Very good. Open up the CRMK office in Germany.

Benedikt: Yes,

Neil: Thanks so much for sharing your ALM expertise with us and we will catch up with you soon. Hopefully I'll be making my way north for one of the summits in the next year or two and we'll see you there.

Benedikt: Perfect. Thanks for having me.

​

Neil: I hope you enjoyed that episode with Benedikt Bergmann. Thanks for joining me, Benedikt. I appreciate you staying up late at home in Stockholm to join me here in Brisbane. If you'd like to check out Benedikt's deep dive course into Power Platform ALM, remember to check the show link in the show notes.

It's on the 29th and 30th of August, 2023. From 9:00 AM to 4:00 PM Central European Summertime. It'll be awesome. You'll find a registration link in the show notes at amazingapps.show/147. 

I'm trying to persuade Benedikt to create an on demand, online version of the course. If that's something you'd be interested in, perhaps you missed his live course, you're tuning into this episode later, or the timing just doesn't work for you, let Benedikt know. Comment down below if you're on YouTube or on the Customery company page on LinkedIn, if you're listening to the audio podcast.

That's it for this episode. Thanks for joining me. Until next time, keep experimenting.