Featured

Thala Dhoni and his Leadership Skills

It’s that magical time again when the world stands still and hearts beat in unison, all for a glimpse of the legend on the green.

Billions hold their breath, eyes glued to the pitch, as the veteran strides out, his bat a wand that might cast a spell with just two swings. Whether he graces us with a soaring six, a swift four, a humble single, or even if the stumps are shattered, it matters not. Our spirits soar with his every move, our patience unwavering.

We’re there for the thrill of his strategy, the joy of his smile, the nostalgia in his flowing locks, the intensity in his gaze, and the sheer brilliance of his glove work. Victory may grace him, or defeat may loom, but our loyalty never wavers. Even if the clock strikes midnight, the match is lost, and the weight of tomorrow’s commitments looms large, we linger for the closing ceremony, hanging on his every word.

In the stadium, his name echoes, turning the sea of spectators into a golden wave of adoration. At home, our vision blurs with tears of pride and the bittersweet tang of a farewell that might be lurking just around the corner. For in these moments, we’re not just fans; we’re witnesses to history, to the twilight of an era that has touched our souls.

True aficionados understand—it’s a connection that transcends the accolades, the centuries scored, and the mesmerizing stumpings. It’s about the moments that take our breath away, the heartbeats that sync with the crack of the bat, and the collective gasp of a crowd in awe. It’s the essence of passion, the shared journey of highs and lows, the silent understanding that what we’re witnessing is more than just a game. It’s a legacy etched in the annals of time, a bond forged in the crucible of play—Yes, ‘Athayum thaandi‘, indeed, something that goes beyond a typical fandom!

My fascination with M.S. Dhoni began with the thrill of watching him send the ball soaring over the boundary. That obsession evolved into steadfast loyalty as he clinched victories after victories. But it blossomed into love when he exemplified humility, serenity, and the art of leadership—teaching me that true greatness lies not just in triumph, but in the grace of one’s character. 

Each of us finds solace in our own sanctuary. Some find it in yoga, others in the melodies of music. For me, it’s in the essence of Dhoni. Watching him on the field is my meditation, his words my mantra, and the respect he garners my inspiration. In his presence, life’s confusion and noise fade away, leaving a calm that echoes his composure. Yes, there are many things to learn from Dhoni. Some of which will help you become a great leader.

Great qualities of the leader – Dhoni:

  1. Inspire: When the strains of Dhoni’s tale from ‘Put Chutney’ fill the room, my wife senses my worries, but my daughter sees the spark of joy that’s about to ignite. Dhoni isn’t just a balm for our bruises; he’s the fire that fuels our comeback spirit. A true leader doesn’t just lead; they inspire, setting a standard that beckons others to rise.
  2. Composure: In the face of setbacks, Dhoni’s demeanor is a masterclass in composure. His unwavering smile, whether in victory or defeat, is a testament to staying grounded, reminding us that serenity is the true hallmark of strength.
  3. Process Over Outcome: Dhoni’s wisdom lies in valuing the journey over the destination. He always talks about the focus on the process. A robust and meticulous process paves the way to success, shaping outcomes one step at a time.
  4. Knowledge Sharing: Just as Dhoni generously mentors the next generation, we too should embrace the power of sharing. It’s the secret to collective growth.
  5. Trust Building: Victory is a team effort, rooted in the trust that you can lead the way. Dhoni, the finisher, exemplifies this trust. He stays till the end. He trusted players others never would have trusted!. This two-way trust is evident in DRS decisions. Even as the world awaits the third umpire’s call, his team celebrates, assured by his confident appeal.
  6. Loyalty: Loyalty is the currency of leadership, extending beyond superiors to every team member and supporter. The loyalty you offer is the loyalty you’ll receive, creating a circle of mutual respect and support.
  7. Appreciation: Dhoni’s way of celebrating triumph—sharing the glory, stepping back for the team photo—shows the power of appreciation. It’s a leader’s endorsement that can elevate the entire team’s spirit.
  8. Embracing Failures: Failures are but milestones on the path to success. Dhoni’s grace in defeat, owning every setback, teaches us that leadership is as much about embracing our falls as it is about savoring our victories.

For countless hearts, he’s the hero who defies the odds. For others, he’s God.

But for me, he’s ‘athayum thaandi’—a presence that transcends all titles and honors.

With every fan’s whisper, there’s a silent prayer—may this not be his final bow.

Dhoni might not be a captain now, but he’s the captain of the masses, endrum engal thala—forever etched as our leader.

Embrace his spirit. Embrace the positivity. Be like Dhoni.

Write your own skill.md – before someone else does

Through the lens

A friend mentioned last week that his company is asking everyone to write a skill.md for their role.

My first reaction: that is the first draft of your replacement.
My second: write it anyway – before someone else does it for you.

What a skill.md actually is

A SKILL.md is a plain text file that teaches an AI agent a specific workflow. It describes what the skill does, when to trigger it, and the steps to follow. An agent reads it, loads it when a matching task arrives, and executes – no human required.

As of early 2026, the format is supported natively by over 30 major AI tools: Claude Code, OpenAI Codex CLI, GitHub Copilot, Google Gemini CLI, Cursor, Windsurf, and others. It is an open standard and the library is growing fast – tens of thousands of community skills exist across major platforms.

One skill in Vercel’s library – a framework that guides AI through hypothesis generation, structured analysis, and slide creation, replicating the workflow of a McKinsey consultant – averages 445 installs a week.

This is not prototype territory. It is live infrastructure.

The honest picture

I am not going to dress this up in alarm, but I am not going to pretend the direction is not clear either.

Research from BCG and the WEF points to the same conclusion: over the next two to three years, 50–55% of US jobs will be reshaped by AI – not wholesale replacement, but a shift in where human contribution sits inside a role. The WEF’s Future of Jobs Report projects AI will create far more roles globally than it eliminates by 2030, while acknowledging that the disruption in between is substantial. UK Government analysis found that the large majority of workers are in occupations where AI can already perform or enhance significant portions of the work.

The pattern that emerges is consistent: the most exposed tasks are the documented ones. The rule-based, step-by-step, reproducible work – requirements capture, standard analysis, configuring to known templates, building initial deliverables from established patterns.

For functional consultants, some of that list will feel uncomfortably familiar.

But this is the wrong frame to start from. Here is a more useful one.

Use it as a mirror

Try this exercise: write ten bullet points describing what you actually do in a typical working week. Then ask of each one – could this be captured in a skill.md? Could you write a step-by-step procedure that an agent could follow to produce this output?

Some of them will fit. That is honest and useful information. The right response is not to resist that – it is to automate those parts yourself, clearing space for the work that matters more.

Because the parts that do not fit are the important ones.

The call where you changed direction mid-conversation because you read something in the room. The instinct you had that a programme was drifting before anyone named it. The judgement call on who to brief informally before the formal review. The way you hold a client’s confidence steady through a difficult phase when nothing looks resolved yet.

None of that fits in a markdown file.

Those are the parts of your work that grow in value as the documented layer is automated.

Writing your own skill.md forces this distinction into clarity. It gives you a map – not of what will be replaced, but of what you should deliberately protect and build.

The human layer that compounds

Across research from the WEF, BCG, and LinkedIn, the same cluster of capabilities appears consistently as growing more valuable in an AI-augmented working environment:

  • Judgement under ambiguity – making the right call when the playbook runs out
  • Curiosity that interrogates AI outputs rather than accepts them
  • Emotional intelligence and the ability to build trust in high-stakes relationships
  • Organisational literacy – understanding how decisions actually get made, not just how they are supposed to
  • Strategic storytelling – translating analysis into meaning that moves people to act
  • The courage to lead when the path is not yet clear

LinkedIn’s Workplace Learning Report 2025 shows AI-related skills being added to profiles at nearly five times the rate of other skill categories tracked. The direction of travel from hiring data is clear: organisations want both AI capability and human judgement – not one without the other.

A practitioner who reviewed one of these AI-built consulting skills captured the gap precisely: it executes boilerplate analysis without the Socratic questioning that surfaces unstated assumptions. That, he noted, is the part AI is still learning.

That is where it is worth investing.

The barber story – and the impact nobody discusses

A few weeks ago I was getting my hair cut. The barber and I got talking about AI. He laughed and said he was clearly safe – he knows how to read a client, how to keep the conversation going, how to make someone comfortable in the chair. A robot cannot replicate that.

He was right. For now.

But on the drive home I thought about it differently. The risk to him is not that a machine cuts hair. It is that his clients – knowledge workers, analysts, consultants – face compressed incomes and tighter budgets. Discretionary spending, a good haircut among it, gets cut first. The route from AI to the barber chair is indirect – but it is real.

This is the second-order effect that gets lost in most AI coverage. AI does not need to automate a role to affect the people who do it. The economic chain connects knowledge work to everything else in ways that are structural, not visible in individual job descriptions.

The barber is safe from the robot. Whether his clients can still afford him is a different question.

Understanding this is not pessimism. It is context for what is actually shifting – and why building higher-value capabilities matters now, not later.

The evolutionary argument

Every major technological shift has followed the same pattern. The Industrial Revolution did not end human employment – it shifted the premium to design, supervision, quality control, and coordination of machines. The computing revolution did not end office work – it shifted value to knowledge architecture and judgement that computers could not replicate.

The environment changes. The humans who adapt most deliberately – who identify what the new environment rewards and build those capabilities intentionally – are the ones who create the next layer of value.

Write your skill.md. Use it as a mirror. Look at what is in it – and deliberately build the layer above.

Be the professional who designs the skill architecture, governs the agent stack, interrogates the outputs, holds the relationships, and makes the judgement calls that no markdown file can encode.

That professional’s value has not been reduced. It has grown.

My first reaction to skill.md — that is the first draft of your replacement — was a version of that same drive-home thought, pointing back at me. Working through my own since, I can see it was the wrong frame. You are not documenting your replacement. You are drawing the line where your contribution begins.

His chair stays full.

The challenge this week: Write ten bullet points describing what you actually do. See how many would fit in a skill.md. The ones that would not – that is where your future is.

Mike Richard is a 3x Microsoft FastTrack Recognised Solution Architect working across enterprise AI, programme delivery, and the Microsoft ecosystem. He writes regularly at mgrb.in and connects with practitioners on LinkedIn.

Where to Start With AI: 9 Phases From Beginner to Builder

Through the lens

From phone tap to frontier: the nine phases of personal AI adoption

A lot of people I speak to feel like they have missed the AI moment.

They haven’t. They have just never seen the map.

There is a natural learning progression to AI adoption – nine recognisable phases, from opening a chat interface for the first time to building systems where multiple AI agents coordinate automatically. Each phase teaches you something specific. Each one lays the groundwork for the next. The sequence is not invented — it reflects how people genuinely acquire new technical capabilities, a pattern consistent with decades of skill acquisition research.

The reason so many people feel stuck or overwhelmed is not that AI is too complex. It is that they are either starting at the wrong phase, or trying to jump ahead without the foundations in place. Both feel the same from the inside: like AI just doesn’t work for you.

It does. You just need the map.

Phase 1 – The phone tap

You open Gemini, ChatGPT, or Copilot on your phone and ask it something. An answer comes back. At first, it feels like a smarter search engine. For many people, the first encounter is not text at all – it is a voice conversation with Gemini Live or ChatGPT voice mode, or generating an image with Copilot Designer. The medium varies. The learning is the same.

Then at some point, it gets something confidently wrong. Yet that moment is more valuable than it seems. You have just encountered your first hallucination – and you have started building the most important skill in AI literacy: critical evaluation. Not blind trust. Not blanket scepticism. The beginning of a calibrated instinct that everything after this depends on.

Over 800 million people use ChatGPT every week. You are not behind. You are at the start.

What you learn: Conversational AI works – and it also fails. Both are important to experience.

Phase 2 – Context and memory

You discover that AI quality scales directly with the context you give it. You start using persistent workspaces – Perplexity Spaces, ChatGPT Projects, Claude Projects – where you can pre-load documents, set custom instructions, and carry knowledge across conversations.

What you learn here is fundamental: the AI is not magic. It works with what you give it. In practice, the people who get remarkable results from AI are not using a different tool. They are giving it better context.

This phase also teaches you what context windows are – the limits on how much an AI can hold at once. Understanding those limits is what separates someone who uses AI well from someone who is constantly frustrated by it.

What you learn: Garbage in, garbage out. Better context, better output. This is also where prompt engineering begins – the practice of writing precise, well-structured instructions to get consistently useful results. It is a learnable skill, not an innate talent, and naming it matters.

Phase 3 – Model literacy

Over time, you start to realise that different AI models are genuinely different tools. Claude reasons differently from GPT. Gemini integrates differently with Google Workspace. DeepSeek approaches problems differently again.

As a result, you stop treating AI as one monolithic thing and start treating it as a set of different instruments. You develop opinions about which model handles which type of work best. That sounds like a small shift – but it changes everything about how you approach AI-assisted work.

What you learn: Match the model to the task. Not all AI is the same.

Phase 4 – Going pro

You make a deliberate financial commitment to a paid tier. Claude Pro, Gemini Advanced, Perplexity Pro – each roughly twenty pounds a month. In doing so, you make a decision: this is a tool worth taking seriously.

Inside those tools, you encounter something important: system prompts. Persistent instructions that shape how an AI behaves across an entire session. You start designing workflows rather than firing off single questions. You think in sequences – first the AI does this, then I review that, then the AI takes my feedback and goes again.

This is where AI shifts from “answering questions” to “working with you.” It is also where most people quietly stop – not because it is too difficult, but because no one ever told them this was the stage to push through.

What you learn: Workflow design. AI as a repeatable process, not a one-off query.

Phase 5 – Into the code

You start using AI to help you write code, scripts, or formulas. Maybe that is Python. Maybe it is Power Automate expressions, Excel formulas, or SQL. The specific language does not matter.

What matters is what this phase teaches: AI-generated output requires verification. You cannot evaluate what you cannot at least partially read. This is the phase that builds genuine confidence in AI as a collaborator – because you learn where its edges are.

A 2025 study found experienced developers were 19% slower when using AI tools – but 90% faster on boilerplate tasks. The gap comes down to one thing: whether you can review what the AI produces. Those who can, capture the upside. Those who cannot end up slower, not faster. GitHub’s 2026 enterprise data puts a number on the upside: PR review time dropping from 9.6 days to 2.4. Building that reviewing muscle is the real work of phase 5.

What you learn: AI output is a draft, not a deliverable. Verification is the skill.

Phase 6 – The terminal

You start directing AI from the command line – via tools like Claude Code, Aider, or Gemini CLI. No longer working through someone else’s interface. The work happens through API keys, scripts, and shell commands.

From there, you learn how AI APIs work. You also start scripting AI workflows. You discover that AI can be a component in a larger automated process, not just a conversation partner. This is the phase that separates people who use AI tools from people who build with AI.

What you learn: AI is programmable. It is a component, not just a chat interface.

Phase 7 – Multi-agent orchestration

You build systems where multiple AI agents coordinate with each other. One agent researches. Another drafts. A third reviews and flags issues. You have moved from AI as assistant to AI as a team.

For example, a delivery team I worked with built an agent that took a process normally requiring four to five hours down to under an hour. That was phase 7 in practice – an orchestrated system that understood context, followed instructions, and handed outputs between agents reliably. It only worked because the team had genuinely moved through phases 2 to 6. You do not build reliable agents on a foundation of phase 1 experience.

This is also the phase where RAG – Retrieval-Augmented Generation – becomes essential. Rather than relying solely on what a model was trained to know, RAG connects agents to live documents, data sources, and knowledge bases. It is what separates agents that are genuinely useful from agents that confidently make things up.

What you learn: Orchestration patterns. How to design systems that operate with minimal human intervention at each step. And how to ground those systems in real, current information.

Phase 8 – Customise and fine-tune

You move beyond using AI models as they come out of the box. You start adapting them. Custom GPTs, fine-tuning a base model on your own data via API, building a Claude Project with a specific character and persona – this is the phase where you stop configuring AI and start shaping it.

Here, the distinction matters. Phases 1 through 7 teach you to work with AI as it arrives. Phase 8 teaches you that the model itself is malleable. You can train it on your writing style, your domain knowledge, your organisation’s specific terminology. A fine-tuned model does not just follow instructions – it has absorbed a context you built for it.

This phase also teaches something equally important: fine-tuning is not always the answer. Better prompting resolves most problems. RAG resolves most knowledge problems. Fine-tuning is the right tool for a narrower set of cases – style, accent, deep domain specialisation – and understanding when to reach for it, and when not to, is part of what this phase develops.

What you learn: The difference between instructing AI and training it. When fine-tuning is the right tool – and when it is not.

Phase 9 – Sovereign AI

You run AI entirely on your own hardware. No data leaves your environment. Models like Llama, Mistral, or Qwen run locally via tools like Ollama.

For most individuals, this phase is optional – more curiosity than necessity. For organisations in regulated sectors, healthcare, financial services, public sector – it is increasingly the destination. Even for personal use, running a local model teaches something valuable: AI is infrastructure, not just a service.

What you learn: Data sovereignty in practice. Cost, control, and capability trade-offs.

9 Phases of AI Adoption

The transitions that define the journey

The shift between phases is not just a tool change. It is a cognitive one:

  • Phase 1 to 2: “AI answers questions” to “AI needs context to be useful”
  • Phase 2 to 3: “My AI tool” to “different models for different jobs”
  • Phase 3 to 4: “I use AI” to “I design AI workflows”
  • Phase 4 to 5: “AI writes prose” to “AI writes executable logic”
  • Phase 5 to 6: “AI assists me” to “I direct AI programmatically”
  • Phase 6 to 7: “One AI pipeline” to “multiple AI agents coordinating”
  • Phase 7 to 8: “I orchestrate AI” to “I shape the AI itself”
  • Phase 8 to 9: “Cloud AI I control” to “infrastructure I own and govern”

Each shift changes the central question – from “what can AI do?” to “how do I build AI systems that do this reliably?”

Why this matters beyond personal use

Here is where the personal journey connects to something larger.

The teams delivering real results with AI in enterprise programmes are not the ones with the biggest budgets or the most advanced platforms. They are the ones where the people involved have genuinely moved through these phases themselves. They understand what AI can and cannot do because they have encountered both, at every level of the stack.

The data backs this up. Organisations that pair AI investment with structured capability building are nearly twice as likely to report strong ROI – 42% report significant returns when upskilling is structured, versus 21% without, according to a 2026 DataCamp/YouGov survey of over 500 enterprise leaders.

You cannot shortcut this with a workshop or a certification. The literacy is experiential.

If you are feeling behind on AI right now, the answer is not to read more reports about it. Instead, open the app, start at phase 1, stay curious, and let the progression do its work.

Which phase are you at right now? Drop it in the comments.

About the author

I’m a Microsoft FastTrack Recognised Solution Architect. I design AI-augmented delivery systems and help enterprise teams move through the phases – not around them.

Connect on LinkedIn: linkedin.com/in/mike-richard

Everyone’s an AI expert. Nobody’s governing it.

Through the Lens

There is a difference between using AI and understanding what it takes to deploy it responsibly in an enterprise.

That distinction is getting lost. Quickly.

Chatting with an AI assistant on your phone, generating a report summary in Copilot, asking a chatbot to draft an email – these are genuinely useful things. They are also not the same as designing a governed, secure, enterprise-grade AI system. The people who can do the former are now, in large numbers, advocating for – and in some cases leading – the latter. Without the guardrails. Without the architecture. With full confidence that the technology is accessible enough that the hard questions can be figured out later.

They cannot be. And if you have spent any meaningful time delivering enterprise technology, you have seen exactly where that assumption ends up.

Across enterprise technology delivery, the same pattern has repeated with every major platform wave: a powerful capability arrives, governance is treated as a follow-on activity, and the cost of that decision arrives at the worst possible moment. AI is not a new story. It is the same story – with a larger blast radius.

Here are a handful of patterns from many I have encountered that illustrate exactly how this plays out.

SMS integrations – when automation runs without a governor

Back in 2015, a delivery team was building a fault and case management system on Microsoft Dynamics CRM 2016 for a major UK energy network operator. Part of the solution included a console application that triggered SMS notifications to customers via an SMS gateway – firing alerts based on power cut events logged in the system.

The logic made sense in isolation. In practice, the application began firing multiple messages for the same event. Loop conditions. Overlapping triggers. No coordinated opt-out enforcement. Customers were receiving repeated messages they had not asked for – it escalated internally, customers were contacted directly to explain what had happened, and the team spent time unpicking automations that should never have fired in the first place.

Under UK GDPR, every one of those messages requires a documented lawful basis, explicit consent, and a functioning opt-out mechanism. The right to withdraw consent must be as easy as giving it. Those regulatory obligations did not arrive to make life harder. They arrived because enterprises, left to govern their own communication automation, consistently did not.

The technology worked. The governance around it did not.

CRM data hoarding – collecting everything, planning nothing

When CRM platforms became powerful and accessible, the default instinct was to capture as much as possible. Names, contact details, purchase history, interaction logs, inferred preferences – all of it, everywhere, indefinitely.

Nobody planned for what happened when a customer asked for it all to be removed.

GDPR Article 17 – the right to erasure – was the regulatory forcing function that made organisations confront data they had collected without a retention strategy, stored without classification, and distributed to third-party processors without adequate contractual controls. A valid erasure request under UK GDPR requires knowing every place that data lives: CRM, marketing tools, integration logs, backups, archived exports. The work of answering that question correctly is significant when it has never been thought through.

This is governance debt – every week you operate without a data classification strategy, you are borrowing against a future cost that compounds. AI agents today are consuming vast quantities of internal and customer data to build knowledge bases, ground responses, and take actions. The same reckoning is coming. The question is whether organisations design for it now or scramble for it later.

Power Pages OData – the danger of assuming defaults are safe

In 2021, security researchers at UpGuard identified a widespread misconfiguration pattern across Microsoft Power Apps portals – now known as Power Pages. The issue was not a flaw in the product itself. It was an assumption made by the people configuring it.

Power Apps portals included the ability to enable OData feeds for retrieving list data. If table permissions were not explicitly toggled on, anonymous internet users could query that data freely. The default state – before Microsoft updated it – required administrators to actively enable table permissions after turning on the OData feed. Many did not, because the assumption was that enterprise software defaults to secure.

38 million records were exposed across 47 organisations as a result – including COVID-19 contact tracing data, vaccination appointments, and social security numbers. Microsoft responded by updating the default behaviour so that table permissions are enabled by default, and released tooling to help administrators audit their existing configurations.

The lesson here is not about the product. Microsoft identified the issue, fixed the default, and provided remediation tooling. The lesson is about the assumption – that because something is enterprise software from a major vendor, it must be configured safely out of the box. That assumption is now being carried into AI agent deployments.

Canvas Apps – a polished front end over an unsecured foundation

Canvas Apps genuinely transformed enterprise UX on the Power Platform. They made it possible to build clean, intuitive interfaces quickly, without writing traditional application code. The problem was what some teams assumed about what sat underneath.

Dataverse security operates at multiple levels: organisation, business unit, team, and user. The most common failure is security roles configured only for primary tables, with lookup and related tables left fully open. The second failure is access control enforced at the Canvas App layer – conditional logic built into the app itself – rather than at the Dataverse layer.

A direct API call bypasses the app entirely and retrieves everything the service account can reach. A polished interface does not imply a secured back end. Dataverse security roles are the enforcement mechanism. The Canvas App is cosmetic. When that distinction is not understood – and it frequently is not – you have an attractive front door on an unlocked building.

Middleware and APIM – integration without a gateway

Azure API Management exists to sit in front of backend services and enforce authentication, IP filtering, rate limiting, and audit logging at the gateway layer. In a well-architected integration, nothing reaches a backend service directly from the public internet.

In practice, I have seen custom integrations in Dynamics 365 and Power Platform programmes bypass APIM entirely – built quickly to meet a deadline, run over accessible public IPs, with no centralised logging and no monitoring in place. The integration works. The project closes. The endpoint stays live. Nobody thinks to decommission it because nobody documented it properly in the first place.

Exposed endpoints do not announce themselves. They are found – sometimes months or years later – by someone who knows where to look. By that point, the team that built it has moved on.

AI – the same pattern, with a larger blast radius

Every one of those failures shared the same root cause. A powerful capability was deployed at speed. Governance was treated as something that would fall into place. It did not.

AI agents in 2026 repeat this pattern – but with greater consequence:

  • Agents inherit the full permission scope of the user or service account they operate under, unless explicitly and deliberately scoped down (Microsoft Learn)
  • 78% of AI users at work are bringing their own tools without employer approval, according to Microsoft’s 2024 Work Trend Index – shadow AI is not a future risk, it is a present condition
  • Prompt injection attacks can redirect agents to exfiltrate data or bypass controls via inputs the agent was never designed to handle
  • AI-generated code introduces security flaws at scale – missing input validation, broken access controls, insecure object references – because the model does not understand the security context of the system it is writing for
  • Gartner predicts 40% of agentic AI projects will be cancelled by 2027, largely due to governance gaps and poor strategic planning

There is also a speed asymmetry that makes this structurally harder than previous waves. AI agents can act in milliseconds. Human governance review operates in days or weeks. The gap between how fast an agent can cause a problem and how fast anyone can detect and respond is architectural – not procedural. It cannot be closed by reviewing logs once a month.

Here is a practical question worth asking right now:

if someone asked you to produce a complete audit trail of every decision your AI agent made last week, could you?

If the answer is not an immediate yes, the governance foundation is not in place.

If you are the person making AI deployment decisions rather than building the agents – that question is yours to answer, not your architect’s.

Microsoft’s own Agentic AI maturity model defines Level 100 – the entry level – as: no AI-specific security or governance processes, agents operating without formal oversight, risk assessment, or compliance checks. Most enterprises deploying AI agents today are at this level.

What responsible governance actually looks like

Level 300 on Microsoft’s maturity model – the minimum for responsible scaling – requires a central agent registry, agents classified by purpose and criticality, environment separation between development, test, and production, standardised approval checkpoints before any agent goes live, audit logging, and documented data handling policies for agent knowledge bases.

None of that is bureaucracy. Every item on that list maps directly to a failure mode described above. This is what closing governance debt looks like – before it becomes a crisis.

Microsoft has recognised this gap. Microsoft Agent 365 brings a central agent registry, DLP for Copilot Studio agents, Zero Trust conditional access, shadow AI detection, and lifecycle approval flows into one place. Useful – but controls without a governance strategy are just features waiting to be misconfigured. The platform does not make the decision to govern. You do.

The point

Consumer AI fluency is not enterprise AI architecture. Knowing how to write a prompt is not the same as knowing how to govern an agent.

Every pattern above was avoidable. Not because the technology was bad – it was not – but because the questions were not asked early enough. Who can access this? What data does this touch? What happens if this fires when it should not? Who is responsible when it goes wrong?

Those questions are not harder to answer before you build than after. They are significantly easier.

If your AI rollout plan has a governance section, check when it starts. If it is after go-live, you already know what this article is about.

Build the guardrails before you build the agent.

About the author
I work at the intersection of enterprise architecture and AI-assisted Business Applications delivery. As a 3× Microsoft FastTrack Recognised Solution Architect, governance is not an abstract concern – it is something I build into every engagement, from the first design session.

If you are working through AI governance in your organisation and want to compare notes, I am always open to a conversation. Find me on LinkedIn or read more on my blog at mgrb.in.

Think First, Then Use AI – The Case for Human-Led Enterprise Thinking

Through the Lens

Before you open that chat window, think

There is a discipline that used to be central to good consulting. It didn’t have a name – it was just what you did. You received a brief, a framework, a set of industry guidelines, and then you sat with it. You asked: does this actually apply here? What needs to change for this client, this industry, this user group? What’s the gap between the generic model and the real problem in front of me?

That discipline – the discipline of interpretation – is quietly disappearing.

I’ve caught myself nearly doing it. You open a chat window, paste in a question, get back a framework, and for a moment it feels like the thinking is done. The output looks convincing. It’s drawn from legitimate published thinking. But nobody has interpreted it. Nobody has tested it against the organisation’s constraints, culture, or users. It’s a template that feels like an answer – and the danger is how convincing it looks.

That’s the problem I want to talk about.

What the research is actually telling us

The question being asked in research circles is pointed: is habitual AI use gradually eroding the cognitive skills professionals most depend on?

MIT’s Media Lab published findings that sparked significant debate. Participants who used ChatGPT to write essays showed significantly weaker brain connectivity on EEG scans compared to those who wrote unaided. Over four months, the AI-assisted group became progressively more passive – cutting, pasting, producing generic output and many couldn’t recall what they had “written” minutes after completing it. The researchers coined the term cognitive debt: the accumulating cost of outsourcing thinking to a machine. The study is small and not yet peer-reviewed, but its direction is consistent with what larger research is finding and even AI tools themselves, when asked directly, acknowledge the risk.

The larger quantitative evidence comes from a peer-reviewed study published in Societies (2025) by a researcher at SBS Swiss Business School, drawing on 666 participants across the UK spanning students, specialists, and senior managers. The findings were striking across three relationships. AI tool use and critical thinking showed a strong negative correlation (r = -0.68). AI tool use and cognitive offloading – the tendency to delegate thinking to external systems rather than engage with it directly – showed a strong positive correlation (r = +0.72). And cognitive offloading and critical thinking showed an even stronger negative correlation (r = -0.75). In plain terms: more AI use leads to more offloading, and more offloading leads to weaker critical thinking. Younger participants showed the highest AI usage and the lowest critical thinking scores. Older participants showed the reverse. Higher education partially buffered the effect – but did not eliminate it. One interview participant in the study put it plainly: “The more I use AI, the less I feel the need to problem-solve on my own. It’s like I’m losing my ability to think critically.”

The Harvard Gazette put this question to faculty across education and philosophy, and the answers were measured but pointed. Researchers at Harvard’s Graduate School of Education noted that the risk is not AI itself – it is using AI as a substitute for thinking rather than an augmentation of it. Generative AI, one researcher observed, does not understand human context. It cannot provide wisdom about social, emotional, and contextual factors, because those are not part of its training. Another drew a parallel to GPS navigation: just as turn-by-turn directions have left many people knowing their current city’s streets in far less detail than streets they learned before smartphones, LLMs will gradually enable professionals to avoid the challenging mental work they stop practising. The consensus across the piece was careful: there are reasons to be optimistic and reasons to be concerned, but treating AI as a general reasoner for any cognitive task at all – rather than a targeted tool within a deliberate process – is where the risk concentrates.

These aren’t anti-AI findings. None of the researchers involved are calling for a return to pre-AI workflows. The concern is narrower: sequence. When AI becomes the first move rather than a later one, the thinking that used to happen upstream simply stops happening. And in enterprise delivery, that upstream thinking is often the most valuable part of the engagement.

The consulting craft that’s going missing

16+ years of enterprise delivery has taught me one consistent lesson: the generic framework is never the answer. It’s always the starting point.

A published architecture pattern for case management doesn’t account for the fact that your client’s agents work across three time zones, or that their legacy system uses non-standard status codes, or that their governance board will never approve a cloud-only solution. The pattern is valuable – but only once someone has done the interpretive work of translating it into a fit-for-purpose model for this organisation, this user group, this set of constraints.

A governance model that lands well in a UK public sector body won’t work the same way in a Japanese enterprise. An integration pattern standard across Europe may be a non-starter for a Singapore financial institution with different regulatory requirements. That translation from generic framework to fit-for-purpose solution is where the real value sits – and no AI tool can do it, because no AI tool has sat in those rooms, read those stakeholders, or navigated those cultural dynamics.

That interpretive work used to be the craft of consulting. It required experience, contextual judgement, and a willingness to sit with uncertainty before reaching for a solution. It was slow, sometimes uncomfortable, and not always billable in an obvious way. But it separated good consultants from people who had read the same published articles as the client.

What I’m observing now – and the research backs this up – is that AI is quietly taking that discomfort away. And when the discomfort goes, so does the thinking.

Ryan Roslansky’s inconvenient reminder

I picked up Open to Work recently – it was recommended by someone from Microsoft at an AI event, and it’s been sitting with me since. Co-authored by LinkedIn’s CEO Ryan Roslansky and Aneesh Raman, the book’s core argument is not a technological one. It’s a human one.

Roslansky identifies five attributes that will define professional value in an AI-augmented world: the 5 C’s. None of them are prompt-engineering skills.

His central argument, as I took it: the future of work will be driven by human creativity and ingenuity, not technology alone. When humans stay at the centre, AI amplifies what people do best.

Reading it, what struck me was how rare genuine clarity has become – not an AI-generated summary, but a real point of view formed by someone who has sat with a problem. That capacity to form an original view before the chat window opens is the professional skill under the most pressure right now.

The sequence is everything

I’m not making an anti-AI argument. In my line of work, I use AI tools to do things that used to take days in a fraction of the time – and I’ve built agents that do the same for others. That leverage is real. But the operative phrase is used well. And used well means used in the right sequence.

Think first. Then use AI.

That’s it. That’s the principle. Before you open a chat window:

  1. Form your own view. What do you actually think the problem is? What’s your instinct about the solution? Even a rough, imperfect hypothesis is more valuable than a clean AI-generated one – because it’s yours, grounded in your direct experience of this client and context.
  2. Use AI to pressure-test, not to originate. Once you have a view, use AI to challenge it. Ask it to identify gaps in your thinking, surface alternatives you haven’t considered, find the research that supports or challenges your hypothesis.
  3. Build on the synthesis. The output you deliver is the product of your judgement augmented by AI – not an AI output with your name on it.

This is what Human-in-the-Loop means in practice. Not a governance checkbox. Not a compliance requirement. A design philosophy: humans originate the thinking; AI extends and accelerates it. The sequence runs human → AI → human, not AI → human → copy-paste.

The cost of getting the sequence wrong

When the sequence inverts – when AI originates and humans rubber-stamp – several things break quietly.

Accountability becomes diffuse. When something goes wrong in a programme built on an AI-generated framework that no one interrogated, who owns the failure? The person who presented it? The tool that produced it? The client who accepted it?

Contextual fit degrades. AI tools train on broad, published knowledge. Your client’s culture, history, constraints, and failure modes don’t appear in that training data. Only the person in the room holds that context. When that knowledge doesn’t inform the AI output before adoption, it never gets incorporated.

Professional credibility erodes. Slowly, and then all at once. Clients are getting better at recognising generic AI output. The consultant who arrives with a genuinely interpreted, contextualised recommendation is becoming rarer – and, as a result, more valuable.

What good looks like now

The professionals who will differentiate themselves in the next five years are not the ones who use AI most fluently. They’re the ones who combine AI fluency with something AI cannot replicate: the discipline to think before they prompt.

Roslansky’s 5 C’s – courage, curiosity, creativity, communication, compassion – are not just soft skills. These are the cognitive and relational capabilities that let a professional do the interpretive work that sits upstream of any AI tool. Curiosity drives the right questions. Creativity shapes the interpretation. Courage means sitting with uncertainty rather than reaching for the nearest framework.

The question worth sitting with – before you open the next chat window – is simple: what do I actually think about this?

Start there. Then use AI to go further.

I’m a 3× Microsoft FastTrack Recognised Solution Architect, specialising in AI governance and delivery, programme recovery, and enterprise architecture. If this resonated, connect with me on LinkedIn: linkedin.com/in/mike-richard

Home » Home » Dynamics

Microsoft Copilot / AI – A day in the life of a power platform developer

The emergence of AI has indeed revolutionized the way tasks are accomplished in various fields. Over the last few months, I have personally experienced the significant impact of AI in my day-to-day work. Its efficiency has played a pivotal role in ensuring that tasks are completed on time, and often even ahead of schedule. This has been instrumental in enhancing productivity and streamlining processes.

I’ve utilized Copilot for a variety of basic tasks. These include crafting chat messages (indeed, what better way to dazzle your superiors with contemporary English?), composing emails, expressing gratitude to my team, offering feedback, drafting documents, designing presentations, and ultimately, developing solutions using Power Platform.

Based on my experience with AI and Copilot, I recently conducted a session highlighting the potential of AI to assist power platform developers and architects in their daily activities.

My session on “Copilot – A day in the life of a developer” followed this agenda

Copilot in your everyday apps

Here, I used the great app-level information provided by Microsoft on this webpage – https://copilot.cloud.microsoft/en-US/prompts. I added a few more icons that I thought were missing on this page. I’m sure many other products have Copilot embedded into them.

Refer to this link on how Microsoft Copilot is better and different – ChatGPT vs. Microsoft Copilot: What’s the difference? – Microsoft Support

The art and science of Prompting

The age of Internet search engines is now replaced by AI. The better the prompt is, the greater the response from Copilot.

My take on prompting involves prompts by two kinds of people –

1. One who doesn’t know what they want.

2. One who knows something and needs more things to be done.

For the first kind, Copilot will act as a mere search engine. You ask a basic question, and it gives the details. It’s for the second kind, that the magic of Copilot is demonstrated and it is also possible only if you understand the science of prompting.

Microsoft talks about the science of prompting in this page – https://aka.ms/copilot/prompt_toolkit?ocid=copilotlab_smc_article_gettips

To summarize, a prompt should have this basic information

  1. Goal – What response do you want from Copilot?
  2. Context – Why do you need it and who is involved?
  3. Source – Which information sources or samples should the copilot use?
  4. Expectations – How should Copilot respond to best meet your expectations

What you can do with Microsoft Copilot?

For this particular topic, I used the toolkit given by Microsoft. It gave many scenarios that you can try out. Do check out the copilot lab link and copilot adoption kits for more information.

https://adoption.microsoft.com/en-gb/copilot/

https://adoption.microsoft.com/en-gb/copilot/success-kit/

Below screenshot is one such example

A day in the life of a power platform developer

I used a requirement about encrypting data using HMAC SHA 256 for my demo on ‘Microsoft Copilot – A day in the life of a power platform developer’. (As I didn’t use MS Team’s Recap or Transcript Feature, here I’m giving a summary of the demo!)

A developer or an architect does the below in their day-to-day life:

  1. Research – The architect/developer gets a requirement from the client. First, they will need to do basic research. You can obviously do this using Copilot for Web, Mobile Apps, and Copilot for Edge. Again this involves the ‘two kinds of people’ that I mentioned in the previous topic. You can ask Copilot for Edge to
    • Search for a topic
    • Summarize a webpage
    • Take a screenshot of the webpage table or diagram and ask Copilot to summarize it in text.
  2. Share – Once they have sufficient information, they have to share it crisply and clearly back to the customer/client. You can achieve this by using Copilot in Outlook. Give the content and ask Copilot to summarize it
  3. Present – This is obvious. You can use Copilot in PowerPoint to create slides based on the content that you share as the source. Unfortunately in my experience, Copilot for PowerPoint didn’t give me a great output. Maybe, I didn’t master the art of prompting!
  4. Document – This is my best use case of Copilot. Copilot for Word can generate pages of the content that you need. In my demo, I asked it to create a technical specification document for the encryption logic with an algorithm, test cases, and even a sample javascript code!. Believe me, it was like magic! I think this is one use case that every developer and every architect needs to embrace!
  5. Implement – For this, I used multiple copilots. I started with a simple javascript by using Copilot for Windows and then used Copilot for Power Pages to tailor the script to work for Power Pages. I then changed the JavaScript to C#.net code that can work as a proper Dataverse Plugin using Copilot for Windows (of course you can try Github Copilot as well). Finally, I built the same logic in Power Automate using Copilot for Power Automate. I also built a simple canvas app to view the source and encrypted data in tables using Copilot for PowerApps.

What have we learnt and what’s next?

Microsoft Copilot is indeed a powerful tool with numerous potential applications in our daily routines. Its ability to assist with code generation and provide insightful suggestions is truly remarkable. As technology continues to advance, it’s exciting to consider the many ways in which tools like Copilot can streamline our tasks and enhance productivity.

I’ve dabbled with Copilot in a slew of my daily grind, but boy, have I been roasted a few times! 😄 From swiping the ‘hello’ from rephrasing suggestions for texts and emails to spouting off facts without double-checking—yep, I’ve seen it all. These AI mirages and my own ctrl+C, ctrl+V blunders? They’re like those spicy life lessons. But hey, they’re seasoning me to be an AI-whisperer!

AI is set to revolutionize the development process by slashing the time needed to create plugins, Power Automate flows, or Power Pages from 8 hours down to just 1. However, the ingenuity of the human mind remains indispensable for crafting the right prompts and integrating the components to produce the intended result.

For now, as we evolve, our jobs are safe. Yes, for now!

What-Why-How | Cloud Power Automates – Myths – General Guidelines

Cloud Power Automates, is a powerful tool that allows users to create and automate workflows between different applications and services.

This article will cover three things

  1. Basic best practices for implementing Power Automates
  2. Myths and Facts
  3. General Guidelines based on my experience

Basic best practices for implementing Power Automates

Here are some basic best practices while implementing Cloud Power Automates:

  1. Plan your workflow: Before creating a flow, take the time to plan out the steps and actions that will be involved. This will help you to create a more efficient and effective flow.
  2. Use templates: Cloud Power Automates offers a wide range of templates that can help you get started quickly. These templates are designed to address common scenarios and can save you time and effort.
  3. Test your flows: Before deploying a flow, make sure to test it thoroughly to ensure that it is working as intended. This will help you to identify and fix any issues before the flow is used in a production environment.
  4. Monitor your flows: Once a flow is deployed, it is important to monitor its performance and usage. This will help you to identify any issues and make any necessary adjustments.
  5. Keep your flows up to date: As the applications and services that your flows interact with change, it is important to keep your flows up to date. This will help to ensure that your flows continue to work as intended.

By following these best practices, you can make the most of Cloud Power Automates and create powerful and effective workflows.

Myths and Facts

Myth: Power Automates are slow

Power Automate, is a powerful tool that allows users to create and automate workflows between different applications and services. However, some users have reported that Power Automate can be slow. Let us explore some of the factors that can affect the speed of Power Automate and what you can do to improve its performance.

Factors that can affect the speed of Power Automate

  • Number of actions: The speed of a flow can be affected by the number of actions it contains. The more actions a flow has, the longer it may take to run.
  • Concurrency: Whether or not you are using concurrency can also affect the speed of a flow. Concurrency allows multiple instances of set of actions to run simultaneously, which can improve its performance.
  • Flow ownership and connections: The speed of a flow can also be affected by who owns the flow and whose connections are being used. If the flow owner or the connections being used are experiencing high load, this can slow down the flow.
  • Load on the source or target: The load on the source or target of a flow can also affect its speed. If the source or target is experiencing high load, this can slow down the flow. For example, understand the throttling behaviours of Dataverse is important!

Myth: Power Automate cannot replace plugins

Fact: It is important to note that Power Automate cannot replace all features of plugins. While it can replace most of the functionalities of a plugin, there are some things that it cannot do. If you need to perform complex operations or calculations, you may need to use a plugin instead of a flow. You might also need to go for plugins if you need to do some actions without an additional DB update.

Myth: Difficult to cancel Power Automate runs

Fact: Another issue that some users have reported with Power Automate is that it can be difficult to cancel runs. However, there are APIs available that can be used to cancel runs, and new features are coming to manage it via Dataverse. https://learn.microsoft.com/en-us/power-automate/how-tos-bulk-resubmit#cancel-more-than-20-flow-runs

Myth: Do not adopt Power Automates as it needs licenses.

Fact: Most customers have sufficient Enterprise Licenses that have Power Automate as part of it. However, before choosing to use Power Automate, make sure to check if you have the required licenses. This will help to ensure that you are able to use the tool effectively and avoid any issues.

While Power Automate can be slow, there are several factors that can affect its speed. By understanding these factors and taking steps to address them, you can improve the performance of your flows and make the most of this powerful tool.

As part of my implementations, I tend to suggest / follow the below best practices. Hope it is useful to you as well:

General Guidelines:

  • Naming Conventions are a set of rules for choosing the character sequence to be used for identifiers in a flow. A good naming convention is crucial for the readability and maintainability of your flows. Here is a sample format for naming conventions in Power Automate:

[TRIGGER TYPE]<<WORKING/TRIGGERING ENTITY>>|<<TRIGGERING ACTION>>|<<Short description of the business logic>>

Some examples of this format include:

  • [Auto] Opportunity | On Change of Owner | Set Assigned To
  • [Manual] Opportunity | Calculate Birthday
  • [Recurring] Opportunity | Once a week | Calculate Birthday
  • [Child Flow] Travel Requests | Approval Logic | Send Approval Request Email
  • [Manual / Parent] Opportunity | Calculate Birthday
  • [Parent] Opportunity | Calculate Birthday
  • [DONOTUSE] Opportunity | Calculate Birthday

By following a consistent naming convention, you can make it easier to understand and manage your flows.

  • Action names and notes are important components of a flow in Power Automate. Action names are used to identify the actions within a flow, while notes provide additional information about the purpose or function of an action. By using clear and descriptive action names and notes, you can make your flows easier to understand and maintain. It is a good practice to use action names that accurately describe the action being performed and to include notes that provide additional context or explanation. An example is given below
  • Basic setup for Dataverse Actions / Triggers: When setting up triggers for a Dataverse action, there are a few important things to keep in mind. Here are some best practices to follow:
    • Use Scope as ‘Organization’: This will ensure that the trigger is scoped to the entire organization, rather than a specific entity or record.
    • Set Run As as ‘Flow Owner’: This will ensure that the flow runs under the context of the flow owner, rather than the user who triggered the flow.
    • Use Column Filters and Filter Expressions. This will help to restrict the flow to a certain set of records / actions

  • Connection references are a way to manage and share connections between flows in Power Automate. When using connection references in Dataverse flows, it is important to follow best practices to ensure that your flows are secure, reliable, and easy to maintain. Some best practices for using connection references in Dataverse flows include:
    • Use connection references to share connections between flows: By using connection references, you can share connections between multiple flows, making it easier to manage and update your connections. Refrain creating multiple connection references as much as possible, else it will be a maintenance headache.
    • Use a dedicated service account / application user for connections: When creating connections, it is a good practice to use a dedicated service account with the minimum required permissions (as non-interactive user). This can help to improve the security of your flows and reduce the risk of unauthorized access. This will also help you to use ‘tenant pool’ and can increase the speed of execution by improving the throttling limits. Using Service Principals or Application users can help to improve the performance of your flows by reducing the load on interactive user accounts.
  • Use environment variables: Environment variables allow you to store and manage configuration data for your flows. By using environment variables, you can easily update the configuration of your flows without having to modify the flow itself. This can help to improve the maintainability and flexibility of your flows.
  • It is important to use ‘Try catch’ logic and ‘Do until’ loops when handling large datasets, such as those with more than 5,000 records. This is because Power Automate has a limit on the number of records that can be retrieved in a single action, and using these techniques can help to ensure that all records are processed correctly.
    • ‘Try catch’ logic allows you to handle errors that may occur when processing large datasets. By using this logic, you can specify what actions should be taken if an error occurs, such as retrying the operation or logging the error for further investigation.
    • ‘Do until’ loops, on the other hand, allow you to repeatedly perform an action until a certain condition is met. This can be useful when working with large datasets, as it allows you to process the records in smaller batches, rather than attempting to process all records at once. Use these loops to make sure you go above and beyond the 5K record limit by using paging cookies.

By using these techniques, you can improve the reliability and performance of your flows when working with large datasets.

  • Child flows are a powerful feature in Power Automate that allows you to create reusable, modular flows that can be called from other flows. Using child flows can have several benefits for both licensing and performance aspects.
    • From a performance perspective, using child flows can help you to improve the performance of your flows by breaking down complex flows into smaller, more manageable components. This can help to reduce the load on the Power Automate platform and improve the speed and reliability of your flows. Additionally, using child flows can help you to better organize your flows and make them easier to maintain and update. You are also splitting the number of actions that each flow has and will execute which can help you to be within the limits.

Do comment with your thoughts / Ideas and Questions. Happy automating!

Cheers.

Through the lens: 10 months of On-Prem – A refresher course – Part 1

D365 On Premise – A Refresher Course

One of my resolutions for this year was to publish a blog article every month. Hoping to resume my blogging journey and share my insights and experiences.

After almost 8 continuous years of meddling with cloud – Azure, Dynamics, and a bit of AWS, I got a chance to come back to the On-Premise version of Dynamics 365. Close to 10 months of 2021 / 2022 have been sort of a refresher course and this time, I was not spearheading the delivery. A client-side application architect role with my day-to-day activities changing almost every day with less control over the deliverables and near zero control over the delivery team.

Photo by Pixabay on Pexels.com

I’m a hands-on architect and this role was completely different from what I used to do. Yes, interesting 10 months.

Like many architects, I prefer sticking to a process. I lay down the platform and make sure my team builds on it. Of course, I have been blessed with some awesome managers, consultants and great team leads / developers to deliver the best. 

But in these last 10 months, I only had a birds-eye view, and interesting enough, it taught me many valuable lessons. I’ll broadly classify them into two categories – Project Delivery and Solution Design.

The delivery side of things.

  1. The art of documentation
    • Documentation is a necessity regardless of the methodology used by the project. Methodology only changes the tools and methods involved in documentation. A typical waterfall model will involve creating a Word document while an agile/kanban/scrum will need user stories in Jira or ADO etc.,
    • Documentation is definitely required when you are requesting an out-of-the-ordinary infra setup, with a clear explanation addressing the – What, Why, and How. In many of my projects, it is normal to give a walkthrough of the document before getting things done.
    • This documentation activity also depends on the right timing. Documents need to be available during the design phase. You can obviously do the required modifications during the build phase.
  2. The urge to share knowledge
    • Every IT project has seen the churn of changing resources. This is part of parcel of life. The quicker we onboard and offboard people (yes, including offboarding), the easier it is to execute a project with the utmost quality.
    • Swift resource rotations are possible only if you have the right ‘Knowledge Base’ set up in your team. It should range from the basics of links to access, architecture, and best practices to the most complex and time-consuming activities that your team does.
    • Knowledge sharing is only going to benefit you more because you move on to the next best thing with your teammate now doing what you already did for many months!. The more you share, the more you gain!
  3. Task planning and tracking
    • There are many simple tools available that can help you plan and track the work of your team. Ranging from simple tools like Microsoft Planners to Advanced tools like Jira /ADO.
  4. Better to delay than to deliver with issues
    • Easy to say, but difficult to practice. Achieving functionality by any means is not the right way to deliver a solution. The technical aspects matter and a project lead should focus on doing justice to the chosen technical components while achieving a solution.
  5. The need for a delivery architect
  6. Roles and Responsibilities
    • Define clear roles and responsibilities. This will help you to achieve your goals with utmost quality as each person will have a specialized skillset and will also keep the morale of your team healthy.
  7. Coding standards, Reviews, and Source code management
    • Typical requirements of any project, when done properly can reduce your delivery time and will also give you a work-life balance. No point in slogging every day, it will only reduce the quality of your deliverable.

Solution design.

  1. Siebel can do, why not D365?
    • Users generally try to compare products. The delivery team must educate the features possible in a product and make sure the product is used in the right way. Focus on increasing user productivity using a next-gen system rather than on building a like-for-like system
  2. Functional and Technical Objectives – The needed balance
    • Same as the previous point. Use the product in the right way. There is no point in customizing it in incorrect ways just to meet the requirements. Educate the users on the advantages of the chosen product instead of building the Impossible in it.
  3. Data Structure
    • Do you know performance issues can be sorted by fixing the data structure? Yes, you can. Try it. Make your data structure linear if you need better performance. This is what AI says for linear data structure:
    • In the context of Dynamics 365 CE (Customer Engagement), a linear data structure can offer several advantages for organizing and managing data. Some of these advantages include:

      1. **Simplicity:** Linear data structures, like lists or arrays, are straightforward to implement and understand. They provide a simple way to store and retrieve data in a single, linear sequence.

      2. **Efficient Access:** Accessing elements in a linear data structure is usually efficient and fast. In D365 CE, this can be beneficial when handling large datasets or performing quick lookups.

      3. **Sequential Processing:** Linear data structures are ideal for scenarios where data needs to be processed sequentially. For example, when performing calculations or applying business logic step-by-step.

      4. **Memory Efficiency:** Linear data structures can be memory-efficient compared to more complex data structures, as they don’t require additional pointers or metadata to manage relationships between elements.

      5. **Easy Iteration:** Iterating over the elements in a linear data structure is straightforward and requires minimal code complexity. This can be helpful when performing operations that involve all records or entities in D365 CE.

      6. **Predictable Behavior:** Linear data structures provide predictable behavior for operations like adding, updating, or removing elements, making it easier to manage data changes.

      7. **Compatibility with APIs:** Many APIs in D365 CE are designed to work with linear data structures. Using these data structures can simplify data integration and data manipulation tasks.

      It’s important to note that while linear data structures offer advantages in certain scenarios, other data structures like hierarchical or graph-based structures may be more suitable for handling complex relationships and nested data in Dynamics 365 CE, depending on the specific use case and data model requirements. Choosing the right data structure depends on the nature of the data and the operations you need to perform on it.
  4. Notifications and the usual troubles
    • How many times has a notification from a non-prod environment reached a customer? I have seen many Android apps send me ‘Test’ notifications.
    • It is fundamental for any delivery team to build notifications with appropriate checkpoints and gates instead of adding whitelisting/turn-off features after an incident occurs. Think about what might go wrong and bring abilities to overcome it as part of your initial design.
  5. Sharing – Great for Jams, not so good for performance
    • My understanding of the Sharing feature of D365 is to give quick access to a colleague or team when needed. I rarely see a static sharing list, meaning 100k records are always shared with a single team or user!
    • We need to understand the purpose and the need for sharing. By Sharing too many records with too many users, you are also missing a way to find out easily who has access to a record, from UI or advanced find. Not to mention the impact on performance. You can increase the infra as required, but fixing the security model is better than pouring your money on infra.
  6. Security model – KISS
    • Keep it simple. Yes, make it easier for anyone to understand how your security model works. D365 CE offers some good features, stick to it.
    • Stay away from client-side security setups like using JavaScripts and implement column security profiles wherever JS might be required.
    • Reduce sharing
    • Use the concept of business units, teams, and additive security roles
      • In Dynamics 365 CE (Customer Engagement), additive security roles allow users to accumulate privileges from multiple roles. When a user is assigned multiple security roles, the privileges from each role are combined, granting the user access to the combined set of privileges from all assigned roles. This additive approach ensures that users have the sum of permissions granted by each role they belong to.

        For example, if Role A grants Create and Read privileges on Accounts, and Role B grants Update and Delete privileges on Accounts, a user assigned both Role A and Role B will have Create, Read, Update, and Delete privileges on Accounts.

        To assign additive security roles in Dynamics 365 CE:

        1. Go to the Dynamics 365 CE environment.
        2. Navigate to “Settings” and click on “Security.”
        3. Open the “Users” or “Teams” section.
        4. Locate and select the user or team you want to assign roles to.
        5. Click on “Manage Roles” or “Manage Roles for Team.”
        6. In the “Manage User Roles” or “Manage Team Roles” dialog, select the roles you want to add from the available roles list and move them to the “Assigned Roles” list.
        7. Click “OK” or “Add” to save the chan

        Remember that additive security roles can lead to a cumulative set of privileges, which might result in more access than intended. Always carefully review the roles assigned to users and regularly audit security settings to ensure that the access remains appropriate for each user’s role and responsibilities.

Part 2 coming soon..

Through the lens: AI and Accessibility

‘Guys, I’m color blind. I can’t figure out what you are talking about’ – This was the complaint of a frustrated client during a workshop I conducted years ago. The workshop was about ‘Design-Thinking’ and the slides were full of colors.

We ignored his feedback and did not change our slides for future workshops. We had many excuses for not making our slides more accessible. The main one was- ‘we did not want to spend time and effort to accommodate one person out of 20 in the room.’

Let’s be real. A common practice among global organizations and enterprises is to incorporate accessibility into their product development. However, how does this translate to the everyday production of technology?

Microsoft 365 products offer a range of accessibility features to help everyone create, communicate, and collaborate effectively. However, some features may not be accessible to all audiences, such as charts with color-coded segments. For example, if I have a chart with a red segment and I refer to it as the Red Segment, some people may not be able to identify it quickly or at all, even with a descriptive legend. A better way to make the chart more accessible is to use labels or patterns instead of colors or to avoid using color names in the text. This way, everyone can understand the chart without relying on color perception.

Accessibility is a topic that caught my attention after reading a piece by a former colleague who is a Thought Leader in this field and experimenting with some AI tools myself. I want to share some insights that I gained from this exploration.

I was curious about how AI can enable people with disabilities to overcome their challenges and access opportunities. Firstly, let’s understand accessibility and AI.

Accessibility is the design and practice of making products, systems, and environments usable by everyone, regardless of their abilities and disabilities. It is not only a human right, but also a social and economic imperative, as more than one billion people worldwide have some form of disability, according to the world health organization. Lack of accessibility can limit people to exercise their right to education, employment, and well-being.

AI – The science and engineering of creating intelligent machines that can perform tasks that normally require human intelligence, such as vision, speech, decision-making, and natural language processing, can actually help in providing accessibility.

In my example, AI can bring the ability to enhance presentations in various ways. For instance, it can detect what the presenter is saying and automatically emphasize the pie chart on the screen. Alternatively, it can translate the color words in the speech to the corresponding colors on the chart and provide audio captions for the listener.

My search to understand AI and Accessibility ranged from reading/scanning multiple articles, evaluating a few common products available in the market, and of course, asking the AI itself.

I also came across this wonderful article on how AI can help with accessibility. I have tried to summarize it below.

The article discusses how artificial intelligence (AI) can be used to improve accessibility for people with disabilities. It provides examples of how AI can be used to help people with visual, hearing, and mobility impairments.
The article also discusses some of the challenges that come with using AI for accessibility. For example, AI systems may not always be accurate or reliable, and there is a risk that they could perpetuate biases or discrimination if they are not designed and tested carefully.
Overall, the article highlights the potential benefits of using AI for accessibility while also acknowledging the need for careful design and testing to ensure that these systems are effective and equitable.

AI is involved in providing better accessibility features, but yes this is only the beginning.

So, as we endeavor to harness artificial intelligence to facilitate people with accessibility needs until such technology becomes ubiquitous for accessibility purposes, it is incumbent upon us to provide paramount accessible functionalities for our clientele and institutions.

Next time, when I build a presentation, I will try my best to be mindful of the audience, and yes, my colorful representation will change to a pattern representation.

Cheers. Let’s do things accessible.

What-Why-How | PowerPages as a mobile app

Product: Power Pages

Feature: Progressive Web Apps

We can create progressive web apps (PWAs) using Power Pages and it’s low-code tools. Yes, you heard me right. You can create web apps that look and feel like native apps, work on any device and browser, and even support offline scenarios. And you don’t need to write a single line of code!

How did I find out about this amazing feature? Well, I was trying to understand a few other features of Power Platform that can help in publishing apps for external and internal users as part of a previous article/session on Native Mobile Apps using Wrap Projects and came across this gem. Yup, I’m pretty late in the game. 🙁

But better late than never, right? So I decided to give it a try.

The design studio lets you create sites as PWAs using drag-and-drop components, templates, and themes. You can customize your app’s name, icon, splash screen, starting page, and more. You can also choose which pages you want to make available offline for your users. And the best part is, you can publish your app to the web or to app stores with just a few clicks.

As usual, there are many blogs that explain step-by-step how to create progressive web apps using Power Pages, but very few explain the need and use cases. My take, here you go…

What are progressive web apps and why do we need them?

A progressive web app (PWA) is a type of web application that combines the best features of native apps and websites. A PWA can run on any device and platform and can work offline or on low-quality networks. A PWA can also access device capabilities such as a camera, microphone, push notifications, and geolocation.

Some of the benefits of using a PWA are:

  • Faster loading time: A PWA can cache the essential resources and data on the device, so it can load instantly and provide a smooth user experience.
  • Responsive design: A PWA can adapt to different screen sizes and orientations, making it suitable for desktops, tablets, and smartphones.
  • Engaging user interface: A PWA can mimic the look and feel of a native app, with features such as app icons, splash screens, home screen installation, and full-screen mode.
  • Offline functionality: A PWA can work even when there is no internet connection or when the connection is unreliable. A PWA can also sync data in the background when the connection is restored.
  • Enhanced security: A PWA uses HTTPS protocol to ensure secure data transmission and prevent malicious attacks.

A progressive web app is a modern way to deliver a high-quality web experience to your users. By using a PWA, you can improve your web app’s performance, usability, and engagement. A PWA can also help you reach more users across different devices and platforms.

Use Cases

One important request that I used to get from many of my implementations is how to get this wonderful PowerApps Portal (or now PowerPages) website that you have built (yes, slightly exaggerated 🙂 ) into each citizen’s (or external users’) hands as a mobile app. Earlier, my response has been they can bookmark the site on their mobile and will need the internet to even read simple ‘text’ pages.

Now my response will be, we can convert these Power Pages into a progressive web app and publish it to the Google play store or Microsoft Store!

Now, how to make sure end users or citizens, or people outside your organization can access your new PWA with login functionalities? You simply need to use Azure B2C / External Identity providers in your Power Pages. Refer to this link on the different authentication mechanisms / Identity providers for Power Pages.

Few use cases:

  1. Public Sector – A local council can publish it’s entire ‘My Account and Services’ PowerPages Website for citizens to use as a mobile app. They can also provide advanced features like push notifications!
  2. Manufacturing / Retail – A warranty/order management registration site can publish its entire Power Pages site for its customers to use as a mobile app to check/register warranties and also create new orders on the fly.
  3. E-commerce: Power Pages PWA can provide a fast and seamless shopping experience, even when the network is slow or unreliable. They can also send push notifications to customers about promotions, discounts, or new products.
  4. Education: Can offer interactive and engaging learning materials, such as quizzes, games, or simulations, that can adapt to different screen sizes and orientations. They can also support offline learning
  5. Travel: Can help travelers find and book flights, hotels, or tours, with features such as geolocation, maps, or calendars. They can also work offline and provide relevant information based on the user’s location and preferences.

and any more. So, use PWA for citizens / external customers and Canvas Wrap projects for Internal Users and Partners.

The steps given on the MS Learn site are pretty clear. You can refer to it here. I have given a few different screenshots and a few additional details in my deck below.

Cheers.

creating-pwa-using-powerpages-1Download