That way I didn't have to have 20 Send Email's, it's adding complexity but making it simpler □ It will be like we own this if we go with complexĪnd he was right, the more complex it is the smaller the developer pool to maintain it, the more likely you will own it for ever, and that adds up to a lot of baggage.īut that doesn't mean I went full simple, some of you may ask why there was a Composein the process, well that was because a wanted to add all the branches outputs and pass it as a single input to the Send Email (the nulls corrupt if passed directly into file content). My friend gave me a great line of advice: So what did I go with in the case study, well in the end I went with the Simple Logic, this was because: This one is very much intuition, the developer has to make the call based on likely hood of growth, added complexity and how much simpler it will be in the future. Here we add complexity to make the future simpler. The above are easy as they are often don't add real complexity, the balancing act is future proofing. Re-ording the process can often improve efficiency by removing duplication. an expression replaces a condition action). Next is to create the process as simple as possible, this needs to be relatively quick and focusing on pure functionality (though still includes our NFR's).įinally we enhance our process, swapping out simple techniques for improved (e.g. From there we build out, it's easier to add the complexity after, then remove it.Ī robust set of Non-Functional Requirements is what everything should be built on, this complexity can't be removed as its value is added after development, this includes basic things like: As a developer our design review is key, as it allows us to identify our bare bones design (If unsure then a spike should be done to find it). The key thing to understand is simple does not = quicker/easier and at the same time complexity does not = benefits. It's a lot more stable and scalable, as additional templates do not add complexity. ![]() ![]() New templates can be added by anyone without developer time. With over 20 variables in uses 208 API callsīut when it comes to maintaining the flow in future it is a lot simpler.Also you can pass anything in, and as long as it's a valid JSON the connector will accept it and use any valid keys/IDs and ignore the rest. Quick Note - If you pass dynamic schema into the Word Connector you have to pass in the variable ID, not the Variable Name/Tag. When the flow ran it would filter list to return correct template name, then loop over all the variables from the variables list and add in the inputs from the MS forms. My second approach was to have a list of templates and variables. It may be easy to add a new branch and template, but that means development which means: Updates to the process could potentially mean updates in 20 places (e.g. That means added complexity in how to manage the templates and any development work. So no environment variables for different templates for Dev/Test/Prod. To keep the simple inputs in the Word connector you must select the template file. Its easy to follow, and if you need to add a new template just add a new branch.Using a Switch I branch the flow into each template, then hardcode the inputs (as the Word Connector reads the template Schema making it a lot easier). More Templates will be added in the future.Each template has unique combination and naming of its variables.Flow selects Word Template based on inputs,Īt first it sounded relativity simple, until you added in the detail:.What drove me to write this blog was a recent automation I was developing, the basics were: less expressions = more actions, and what about: So when you build your next flow keep it simple, easy, but what is simple?īut some of them will contradict each other, e.g. Costs (Limited API calls/Premium licenses).Simplified tool set (Less flexibility in the solution can cause complexity).Varied skills base of developers (most developers self-taught).In fact it's more important in Power Automate then ProCode because: Yet KISS is rarely spoken about when developing in LowCode and especially in Power Automate, with the most likely explanation being "Its LowCodeNoCode so it's already Simple", but that isn't the case. ![]() When coding solutions it is very easy to over engineer solutions, by either flexing (showing off the cool stuff you know) or by not planning. Speak to a senior ProCode developer and you will often talk about the importance of KISS. KISS, an acronym for "Keep it simple, stupid!", is a design principle first noted by the U.S.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |