What are Standards?
Development standards are documented guidelines designed to steer development into a uniformed structured framework. This ensures that solution objects and components all match the same standards before being deployed to production.
Identifying Development Standards
Set scene. You are developing a canvas app and you are OCD with your code. You clearly distinguish between global and local variables, ensure that page names are appropriate to what they hold, and comment above long lines of code so you always identify the codes function. Your solution looks magnificent! Sadly, you happen to get sick one day, and Steve needs to continue with development. Steve however, is a new developer, and has not been introduced to any standards. Once Steve continues on your project, two things are guaranteed to happen:
- Steve will not adhere to your expected development standards. Your solutions look messy now.
- When you return, you are now lost within your own project. You don’t know what button1_1 is and or what it triggers. Great way to get back into it right? There goes another 2 days of trying to understand your code again.
Building Your Standards
Solutions
A preferred method of keeping solution objects contained in a project, is creating a solution wrap around your apps, flows and any other objects included in your project. Creating project orientated solutions is critical, even if it only consists of a single flow or app.
Power Apps
Think about what you feel your code should look like. Taking canvas apps into consideration, let’s start with the OnStart property. You may use the OnStart property to set user permissions, or to create local collections to avoid delegation warnings. As the code adds up, you begin to get lost in it. Formatting your code would be a great start. Following that would be commenting most lines of long code. And when I refer to commenting, not just a few words, give a good description of what that code does.
Naming convention is a big one. Ranging from variables and collections to control names and components. You can distinguish between global and local variables using specific abbreviations such as glb for global or loc for local. You can also place underscores between abbreviations to make it more readable, ie glb_CurrentUser_DisplayName vs glbCurrentUserDisplayName. Ask question like, do we incorporate Camel Case or Pascal Case?
To ensure your solution complies with accessibility standards, it’s also ideal to have proper names for each page. ie, naming your landing page “Home Page” rather than “HomePage” or “Home_Page”. Additionally, your page names should be in relation to what functions will be performed within the page itself. This also branches out to applying accessibility labels, tooltips and focus borders as all these considerations would help with screen readers. All these ideas are going to take you in the right direction.
Power Automate
When working with flows, you should also be naming your actions and triggers appropriately. Having a trigger named “Send email v2” means very little. Expanding it to say “Send email v2 – Send project details to stakeholders” introduces further context into the actions purpose and eliminates having the same named action later on.
Similar to Power Apps, you can also use variables in Power Automate. You don’t need to distinguish between local or global variables, but maybe you want to take into consideration the variable type, be it a string, decimal or boolean. Taking Power Automate Desktop into consideration, you can also start to identify between input an output variable.
Another crucial standard that should exist in Power Automate, is error handling. We all hate it when our flow shows as failed, even it served its purpose correctly. Having error handles and scopes within your flows can ensure that they always run successfully and if any issues do occur, they can be logged.
Power BI, Power Pages and Power Virtual Agents
Without diving too deep into each product, you can also apply standards to these. You can apply naming convention around DAX measures and columns names. You can use primary and secondary variables in CSS for Power Pages as well as identify your classes in HTML. You can also have a structure to naming topics and entities within your chat bots All these impact your development standards.
Data Sources
A really important factor within development standards is how you structure your data source. Whatever your data source is, be it SharePoint, SQL or Dataverse, it is imperative you structure it efficiently. Although you may not be 100% responsible for setting up the data source, having a say as to how you name your columns, what column types are needed and identifying required DIM and FACT tables can impact how you deliver a solution.
Some Ideas
I’d say a good starting point with your designing your own standards should include the following items:
- Naming Convention: Camel vs Pascal, spaces, function etc.
- Code Structure: White spaces, commenting.
- Error Handling: How to deal with errors and exceptions.
- Delegation Warnings: Using local collections etc.
- Theme: Initialize a reusable theme through a variable.
- Accessibility: Tooltips, focus borders and labels.
- Performance: Are all variables and images being used? Are you duplicating variables? Are you filtering queries efficiently?
- Security: Loading data in securely and applying appropriate security roles.
- Adoption: Plan to adopt developers to the new guidelines (overseen A LOT! We’ll touch on this a bit later)
You don’t need to start from scratch. There are plenty of general development standards out there that you can use as a template. The key word however, is TEMPLATE. Make the standards your own. Make them benefit you!
Designing development standards is an essential aspect of a successful Power Platform ALM Governance Framework. These standards will guide developers through a standardised development strategy and structure whilst ensuring your deployed solutions all adhere to the start of your ALM Governance Framework.
