You’ve got a job to do. You have lots of meetings to attend. You have your own code to write. You have the whole architecture of the system to think about.

It is easy to think about reviewing work as an afterthought: as a tick the box exercise.

It is definitely not. Maintaining standards in your codebase and preventing mistakes is your job.

If there is a big security hole in your configuration that eventually gets taken advantage of, it is you that is to blame. If someone else on the team developed an absolutely insane process that you can’t believe anyone could even dream up, it is your fault. If there are global variables used in a parallel loop in a Power Automate cloud flow and it eventually results in one customer’s data going to another’s email address, that is your fault. If there is a hardcoded URL referenced in a rarely used web resource that ends up in calls from Dev going to a Prod system, that is your fault.

In my opinion, not reviewing work and then blaming others when problems are later reported is super, super weak.

It is also lazy. As a side note, I think that this is a bigger problem in not just tech, but in some organisations in Australia and New Zealand. People are often scared of giving timely feedback because they see it as confrontational. And they want to be liked. I get it, we all want to be liked. But it is actually better for the people that you are responsible for, in the long run, if you give them timely feedback when they’re doing well, but that you also correct them on their mistakes, uphold standards so their mistakes don’t result in big failures, and that you hold them accountable. When we do so though, we must always be polite and uphold the mana of those we talk to.

It is hard though, and I am not definitely not perfect at it myself. In fact, I am still learning a lot about my style of general and technical leadership in the IT area. Being a strong leader is hard. But just because it is hard, does not mean we should not do it.

Letting things slip past without being a gatekeeper and hoping things don’t go too wrong is also not as safe as you think. You will get away with lower level mistakes slipping past you from time to time, with little reprecussions.

When something big happens, though, you might plan on using the following excuses, which I have heard from people in technical leadership positions myself:

• “No-one asked me to review the work”
• “I can’t believe they would do that!”
• “I have to be able to expect a baseline of competency”
• “People should self review their own work”

These excuses will not work when the problem is big enough.

You will have your own style for how you conduct reviews. That is okay. As long as the reviews are thorough, and as long as you do not feel scared to give feedback and reject work that is not up to standard or is not secure.

I suggest that you come up with your own framework, but that it should fit into something similar to this:

Developing standards and enforcing them

• Develop some written standards. This does not have to be a huge document (that no-one ever looks at). I suggest one or two pages. Basics. Things like: “Always use try and catch blocks, and handle errors gracefully”, “Never build an unsecured HTTP triggered flow”, “Name things according to what they do (do not use default names)”.
• Communicate your expectations to the team:
  • They know what the standards are
  • Their work complies with them
  • They review their own work against them before they send it through for review
• When the work is submitted to you, ask the developer to confirm they have self reviewed their work. They have to expect to be asked.
• Actually review the work
• If it is up to, or better than your standards, let the developer know they did a good job – positive feedback is important!
• If something is not up to standard, hold firm:
  • Let the person know the problem the first time and ask them to fix it.
  • The second time, consider asking the developer to review their work again and to identify the problem and to fix it
  • The third time you see a similar mistake, it may be time to consider other options like

Things you should do when undertaking a review

• Check for common security mistakes. Things like:
  • Creating a new custom table and not setting up appropriate security roles
  • Registering plugins at the wrong phase (e.g. pre-validation)
  • HTTP triggered Power Automate cloud flows without rate limiting, authentication, or authorization
• Basic:
  • Nulls and empty values are not handled, or are handled poorly
  • Edge cases are not considered
  • Client side processes are used when server side processes should be used
  • Database transactions are not atomic
  • Retry policies (to send HTTP requests or to call child flows) are not set up as expected
  • Variables are used at the wrong scope
  • Expressions in Power Automate cloud flows are correct
• Laziness:
  • Steps in Power Automate cloud flows are not named correctly
  • Variables and functions are named incorrectly within plugins
  • Lack of error handling
  • Lack of error notifications
• Power Automate specific:
  • Cloud flow concurrency is not configured correctly
  • Global variables are used within an Apply to Each loop
  • A Do-Until loop is used without checking if it should be initialised

It is your responsibility to manage your time so that you have time do to this stuff.

A lack of code and configuration review is also a massive security risk. As CRM developers, and particularly as leaders in this space, we have an absolutely huge role to play in securing our organisation’s data. Our role is at least as important, if not more important, than things like library updates, Windows desktop updates, network policies, and typical things that are desginated “security”.

Think about something like the Optus breach in 2022 that allegedly came down to an unauthenticated API endpoint that had been being used for testing. Optus disputes that it was because of this, but if it was down to something like that, it is something that could have easily be done accidentally by a D365 developer asked to work on something they are unfamiliar with. There are lots of “accessories” to CRMs that are often built ad-hoc to allow the CRM to handle a wider scope of activities.

In my opinion CRMs are a blind spot in cybersecurity in Australia at the moment. They are often not “public facing”, there is often a lack of insight from those within the organisation (but not working directly within the CRM project) as to the scope of what the CRM and its accessories are doing, and there is just not much expertise in the topic.

This is something which I want to help fix, even if only at a few organisations for a start, and it is something which I really hope improves over time.

But this article is not just about security, it is also about accepting responsbility, being accountable, being a good leader, and driving better performance.

And that is our job.