In this next post in my series on solution architecture for Power Platform, we’ll take a look at the different options the platform offers us for implementing custom logic for both first-party solutions we customise and our own custom built solutions that as a solution architect you can be considering when it comes to designing solutions you build on the Power Platform!
Options for custom logic
Now when it comes to implementing custom logic for the solutions we build using the Power Platform, there’s a whole range of objects we can use to implement these. A solution architect doesn’t necessarily always need to go as granular as which object should be used for each granular requirement, as sometimes multiple can serve the same purpose, and each will just have pros and cons. There will however be cases where the correct object should be used to deliver a suitable user experience.
| Business Rules | Classic Workflows | Power Automate Cloud Flows |
| Business Process Flows | Calculated Columns | Rollup Columns |
| Plug-ins | Custom workflow assemblies | Custom actions |
| Custom API | Client-side scripting | Power Apps component framework code components |
| Azure Service Bus and Event Hubs integration | Webhooks |
Custom logic object options
Consideration #1 for custom logic – Synchronous vs Asynchronous processing
One of the huge considerations that does need to be made and will affect the object used to implement custom logic is how that logic should be processed, and whether this should be synchronous processing or if it can be asynchronous processing. This consideration can make dramatic changes to the user experience we deliver with an application so it’s important to think about this.
You can think of synchronous logic and processes as processes a user triggers which then blocks their user interface until the processes are complete to then display results created by the process.
Asynchronous processes can be thought of as processes which happen in the background and don’t happen as quickly where the user will see results straight away. You can think of them as separated from what is happening for the users experience a little. These are the kind of processes which may take a few minutes, up to multiple hours and may even sit in a background process queue before being processed.
As solution architects we should have a high level understanding of which objects we can use to support synchronous or asynchronous processing so we design our solutions in the correct way to support the appropriate and required user experience.
Consideration #2 for custom logic – Client-side vs server-side
The next consideration we need to make which is somewhat similar to the previous but a little different is whether we implement logic on the client-side or the server-side. Typically there won’t be much movement in terms of picking one here because the requirement we need to achieve will result in us needing to use an API, or a cloud flow perhaps which by default mean we’re working with server-side logic. This primarily depends on the type of logic we’re implementing and the objects being used but should be thought about when thinking of the user experience to be delivered.
Anything we create which executes on the client-side will typically deliver a more pleasant UX as it will more than often happen instantly, where as anything like calling an API or things that have to execute on the server-side will require things like a refresh to see results and things wont be so instant here.
Make sure as a solution architect you understand the different types of logic here and where they execute to ensure you’re designing appropriate user experiences.
What’s coming up?
So! In the next posts in this series we’ll finish up on broader platform wide architecture topics by looking at platform limitations and finally building for solutions that need to be highly scalable 📈