Microsoft MVP | Power Platform & Dynamics 365 CRM Technical Consultant
I help organisations turn business needs into practical solutions using Microsoft Power Platform and Dynamics 365 — from deciding what to build and choosing the right approach, through development and implementation, to adoption and continuous improvement.
I work across both the business and technical sides of the work. That means understanding how people actually work, working with stakeholders to define what is needed, deciding what is worth changing or automating, knowing when to use an existing Microsoft capability and when custom development is appropriate, choosing the right technology for the problem, and building solutions that are secure, maintainable, user-friendly and adoptable.
The work can start in different places. An organisation might be beginning its Power Platform or Dynamics 365 journey, moving away from legacy systems and manual processes, migrating data from existing systems, legacy CRM or spreadsheets into Dataverse, building a Power Pages website, developing applications and automation, or improving an existing Power Platform or Dynamics 365 solution that is already in use.
I also consider what happens beyond the initial build. Security, environment strategy, application lifecycle management and deployment need to be part of the approach from the beginning. So does helping the people who will use and support the solution through training, workshops, internal communities and a Power Platform Community of Practice.
Return on a Power Platform or Dynamics 365 investment does not come from the licence. It comes from processes that were improved, data that was migrated cleanly enough to be trusted, solutions that remain secure and maintainable a year later, and people inside the organisation who use them and can build on them without external help.
These are the situations I come across most often, written the way organisations tend to describe them.
Starting from the beginning is an opportunity to make good decisions before patterns become difficult to change. I can work with the organisation to understand what it is trying to achieve, what should be built, which Microsoft capability is appropriate, and where an existing out-of-the-box feature is a better answer than custom development.
The work can span requirements and stakeholder engagement, solution design and development, data migration, integrations, Power Pages, Power Apps, Power Automate, Dataverse and Dynamics 365 Customer Engagement. It also means making sure security, environment strategy, application lifecycle management and development practices are considered as part of the work rather than added later.
The technical solution still has to work for the people using it. I look for solutions that are maintainable, user-friendly and adoptable, and work with the organisation to move away from spreadsheets, email-driven processes, legacy systems and manual workarounds where the Microsoft ecosystem can provide a better way of working.
A spreadsheet that three people maintain and nobody quite trusts. Approvals living in forwarded emails. The same information typed into two systems because those systems were never connected. Work that only moves when someone remembers to chase it.
I start by understanding the process as it actually runs, including the parts nobody has written down. From there it becomes clear where automation genuinely helps, where an application would serve people better.
I have written a full worked example of this: How a Finance Team Can Automate Their Payment Approval Process and Build a Full Audit Trail.
An organisation invests in Power Platform. Apps get built. Flows get created. Environments multiply. Then, somewhere along the way, things drift. Adoption stalls once the initial enthusiasm fades. Nobody is certain which apps are still in real use and which have been quietly abandoned. Two teams have built the same thing twice. Security was set up quickly at the start and has never been revisited. There is no clear route from development to production. The person who built the most important flow has left.
None of that means the original investment was wrong. It usually means the platform grew faster than the structure around it, which is what happens when something is genuinely useful.
I can come into that environment and work out what is really there. What is in use, what has been abandoned, what is fragile, what is duplicated, what is a security concern, and what is quietly doing important work with no documentation behind it. From there we can agree what needs attention first, and I can do the work to move it forward rather than just reporting on it.
Sometimes the most valuable work is not building something new. It is understanding what an organisation already has and helping it become more useful, secure, maintainable and adopted.
I do not need everything to start from scratch. I can work inside an environment that already has Power Apps, Power Automate, Power Pages, Copilot Studio, Dataverse, Dynamics 365 Customer Engagement, existing integrations, existing data, existing application lifecycle management processes, existing governance and existing business processes that people depend on. Working with what is already there, alongside the people who built it.
This is the thinking behind The 5 Pillars of Sustainable Power Platform Governance and Adoption, where I set out how the structure around a platform can catch up with its growth.
An implementation can be technically complete and still not work for the people who depend on it. Forms that ask for information nobody has at that point in the process. Business process flows modelled on how the organisation was told it should work rather than how it does. Reporting that leadership does not trust. Users who have quietly gone back to their own spreadsheet.
I work across requirements, stakeholder groups, configuration, development, automation, data migration, testing, training and the continuous improvement that comes after go-live.
This is a better position to be in than it feels, and the first answer is rarely a technology decision.
I look at what the process is meant to achieve, where time is actually lost, where errors actually happen, and who carries the consequences when it goes wrong. Some of what surfaces is worth automating straight away. Some is worth simplifying first, because automating a poor process only makes it harder to see. Some is better left alone, because the effort would outweigh the return. Knowing which is which is most of the value.
An operational example, start to finish: How to Automate Crew Assignment and Job Dispatch for Moving Companies Using Power Automate.
Delivery is not Build, Deploy, Done. It is Understand, Build, Enable, Adopt, Measure, Improve. The last four are where most of the value sits, and they are the ones most often missing from the plan.
A solution nobody uses is not a partial success. It is a cost, and it makes the next project harder, because people remember how the last one went.
Adoption is not a communications exercise bolted on at the end. It is something you design for from the beginning, by involving the people who will use the thing while it is still taking shape, and by being honest when their feedback means the design has to change.
Where I contribute:
The goal is not to deliver another solution. It is to help the organisation get better at using the platform, so the next solution needs less of me and more of them.
On building something that lasts beyond the person who started it: How to Build an Internal Community That Stands the Test of Time.
I am interested in working with organisations over the longer term, including from within the organisation itself. I am also open to relocating where there is a strong fit. I am based in Malta.