Final chapter of the series «The Evolving Functional Role in Microsoft Fabric»

Throughout this series, we have explored how Copilot is transforming the way functional professionals engage with data. We have seen how it assists with data preparation, helps uncover insights and enables a deeper understanding of business information.

But all these advances ultimately lead to a much larger question:

What happens when users stop searching for information and information begins responding directly to them?

1. For Decades, We Learned to Speak the Language of Machines

The history of business analytics is, in many ways, the history of translation.

Business leaders think in questions.

Systems respond in technical language.

Between these two worlds, there has always been a layer of intermediaries:

• Business Analysts
• BI Specialists
• Data Engineers
• Data Analysts
• Solution Architects

When a Commercial Director asked:

«Why is profitability declining?»

the organisation typically translated that question into:

• SQL queries
• Data models
• Measures
• Business rules
• Visualisations
• Reports

Technology evolved.

The translation layer remained.

Despite major advances in analytics platforms, the process still required users to understand where information lived, how it was structured and how to navigate it effectively.

That dependency became the hidden cost of data-driven organisations.

The image visually represents the transition from data exploration to natural conversation.

2. The Real Revolution Is Not Artificial Intelligence

A common misconception exists across the industry.

Many professionals believe the breakthrough lies in generating queries more quickly or creating reports more efficiently.

That is not the fundamental shift.

The true transformation lies in the removal of complexity.

For the first time, business users can focus entirely on their objectives rather than the technology required to achieve them.

They no longer need to understand:

• SQL
• DAX
• Data structures
• Table relationships
• Data warehouses
• Lakehouses
• Semantic models

Instead, they focus exclusively on the business question.

The platform determines how to answer it.

The experience changes from navigating technology to expressing intent.

The complexity does not disappear.

It becomes invisible.

Functional Example

A Finance Director asks:

Which product categories have experienced the largest margin decline this quarter compared with the same period last year?

Traditionally this would involve:

• requesting a report,
• validating assumptions,
• waiting for analysis,
• reviewing multiple visualisations.

Now the interaction begins with a simple question.

The conversation replaces the process.

3. Semantic Models Become Organisational Knowledge

Traditionally, semantic models were designed to support reporting.

Their primary purpose was to provide consistency across dashboards and analytical solutions.

Today their role is becoming significantly more important.

Organisations are increasingly building semantic models not just for users but for intelligent systems.

This changes everything.

Semantic models are no longer simply:

• analytical structures,
• governance mechanisms,
• metric repositories,
• reporting foundations.

They become representations of organisational knowledge.

They provide business context.

They define meaning.

They establish trust.

Most importantly, they enable intelligent systems to understand the language of the organisation.

In this new paradigm, the semantic model is no longer the destination.

It becomes the starting point for every conversation.

Semantic Model and Data Agent architecture

4. The Final Democratisation of Data

For years, technology vendors have spoken about democratising data.

Progress has undoubtedly been made.

Yet one challenge remained.

Users still needed to:

• locate reports,
• understand metrics,
• navigate pages,
• interpret visualisations,
• connect insights.

Even with self-service analytics, the burden remained on the user.

Conversational intelligence changes the equation.

Business users interact using the only interface they have mastered since childhood:

language.

They ask questions exactly as they would during a management meeting.

Examples include:

Which suppliers have increased costs most significantly this year?

Which customers are showing early signs of churn?

Which regions are exceeding their sales targets despite market contraction?

The barrier between data and decision-making becomes significantly smaller.

For many organisations, this may be the first genuine step towards universal data accessibility.

5. The Emergence of Enterprise Conversational Intelligence

Perhaps the most profound shift is not technical.

It is organisational.

Data is no longer confined to analytical platforms.

Intelligence begins to appear wherever employees work.

Imagine a sales executive opening Microsoft Teams and asking:

Which European customers present the highest revenue risk over the next quarter?

The system analyses organisational knowledge, business definitions and historical patterns.

The answer appears within the natural flow of work.

No dashboard.

No navigation.

No training course.

No technical intervention.

The user remains focused on decision-making rather than information retrieval.

This changes not only how analytics operates.

It changes how organisations think.

Data Agents integrated with Teams, Copilot Studio and enterprise applications

6. Will Analysts Become Less Important?

Quite the opposite.

As technology reduces technical barriers, business understanding becomes more valuable.

The competitive advantage shifts from:

«I know how to access information.»

to

«I know which questions matter.»

Professionals who understand:

• processes,
• operations,
• customers,
• finance,
• strategy,

will become increasingly important.

Technology can retrieve information.

Only people can define which problems are worth solving.

7. What This Means for Functional Professionals

Functional consultants have traditionally served as translators between business and technology.

That responsibility is evolving.

Less time will be spent on:

• explaining data structures,
• validating queries,
• navigating technical complexity.

More time will be devoted to:

• process design,
• governance,
• adoption,
• strategy,
• business transformation.

The role does not diminish.

It becomes more strategic.

The ability to frame problems correctly may become more valuable than the ability to build solutions.

To Conclude

Throughout this journey we have explored how intelligent technologies are reshaping the functional landscape.

We have seen how they:

• simplify complex processes,
• accelerate analysis,
• enhance decision-making,
• strengthen business understanding.

But perhaps the most significant transformation is this:

Data is no longer something we search for.

Data becomes something we speak with.

This is not merely the evolution of reporting.

It is the evolution of the relationship between people and information.

And once organisations begin having conversations with their data,

it becomes very difficult to return to searching for answers the old way.

Final Reflection

The next generation of business professionals will not be recognised for their ability to build reports. They will be recognised for their ability to ask better questions.

Episode 4 — The Semantic Model as a Cognitive Layer in Power BI: When Copilot Stops Describing and Starts Reasoning

Copilot doesn’t transform your data. Copilot transforms how your semantic model thinks.

This episode marks a turning point: Power BI is no longer just a visualization tool. It becomes a reasoning system, where the semantic model acts as a cognitive layer capable of interpreting, inferring, and sustaining business logic.

This is not about functional intelligence. This is about structural intelligence.

1. The semantic model is no longer a container — it’s a cognitive system

Business example: A retail chain with 120 stores asks Copilot why “Electronics” sales dropped in Week 32. If the model lacks hierarchies, promotion logic, store granularity, or margin measures, Copilot can only describe.

But if the model encodes business logic, Copilot can reason:

“The decline is driven by inventory shortages across 34 stores and the absence of the active promotion in the northern region.”

Copilot doesn’t invent this. The model does.

2. Copilot doesn’t work on dashboards — it works on logic

Business example: A logistics company wants Copilot to generate a report on route efficiency. If the model only contains trips, vehicles, and drivers, Copilot can describe.

But if the model includes optimal vs actual distance, loading times, delivery windows, penalties, and cost per kilometer, Copilot can infer:

“Inefficient routes correlate with strict delivery windows and high urban density.”

This is business reasoning, not visualization.

3. The new KPI for BI: Can your model reason?

Business example: A bank asks Copilot to explain changes in SME credit risk.

If the model includes risk measures, product relationships, payment history, sector classification, and scoring rules, Copilot can generate DAX such as:

“AdjustedRisk = BaseRisk + SectorPenalty + LatePayments * 0.3”

And explain:

“Risk increased due to exposure to the construction sector and two late payments in the last 12 months.”

This is semantic reasoning.

4. The functional consultant becomes an intelligence architect

Business example: A manufacturing company wants Copilot to identify production bottlenecks.

The functional consultant must now model:

• cycle times
• machine dependencies
• production capacity
• maintenance logic
• shift constraints

This consultant becomes an intelligence architect, defining how Copilot interprets operations.

Copilot doesn’t replace the functional role. Copilot elevates it.

5. The future of BI is not visual — it’s cognitive

Business example: An insurance company wants Copilot to explain why premium vehicle claims increased.

If the model includes risk zones, weather, vehicle type, driver history, traffic density, and policy rules, Copilot can reason:

“The increase is concentrated in high‑congestion zones during rainy days, especially for vehicles older than five years.”

This is contextual reasoning, not reporting.

To conclude

Copilot doesn’t make Power BI smarter. Copilot makes your semantic model visible.

And that forces teams to build models that don’t just represent data… but reason through the business.

This is the real generational shift in enterprise analytics.

Series: “The Evolving Functional Role in Microsoft Fabric” — Part 3 of 5

1. The semantic model becomes a functional intelligence engine

The semantic model has always been the backbone of Power BI. But until now, only technical profiles could truly interpret it.

Copilot changes that.

Copilot understands:

– table relationships

• cardinalities
• hierarchies
• measures
• calculated columns
• business semantics
• filter logic
• metric dependencies

With this understanding, functional roles can ask questions as if speaking to an analyst:

“Which region is generating the highest adjusted margin?” “What trend should concern us this quarter?” “Which product is losing profitability, and why?”

Copilot analyses the model and returns:

• a suggested visual
• a narrative explanation
• a key insight
• a functional recommendation

2. Copilot generates complete report pages from functional intent

Traditionally, building a report required:

• designing visuals
• selecting fields
• configuring filters
• adjusting formatting
• validating measures

Now Copilot can generate entire report pages from a functional intention.

Example:

“Create a page with regional sales, monthly variation and an executive summary.”

Copilot produces:

• a bar chart by region
• a monthly trend line
• a detail table
• an executive narrative
• an insight on the region with the highest variation
• a functional recommendation

This does not replace the technical analyst. It augments them — and allows functional roles to progress independently.

3. Copilot writes, corrects and explains DAX with business logic

This is one of the most transformative capabilities.

Copilot does not only generate DAX. Copilot explains DAX.

Example:

“Explain how the Net Margin measure is calculated.”

Copilot returns:

• the full formula
• the business logic
• applied filters
• column impact
• optimisation suggestions
• potential misinterpretations
• more efficient alternatives 

This enables functional roles to:

• validate metrics
• detect errors
• understand business logic
• explain KPIs to executives
• propose improvements

Without writing a single line of DAX.

4. Executive narratives: the report speaks, explains and recommends

Copilot generates executive‑level narratives that explain:

• trends
• anomalies
• comparisons
• risks
• opportunities
• actionable recommendations

Example:

“Summarise last quarter’s performance.”

Copilot produces:

• a clear narrative
• a variation analysis
• an insight on the root cause
• a functional recommendation
• a potential risk 

This turns Power BI into an analytical assistant — not just a visualisation tool.

5. Functional KPI validation without technical dependency

Copilot enables validation of:

• financial KPIs
• operational KPIs
• commercial KPIs
• service KPIs
• project KPIs

Example:

“Validate whether the Operating Margin KPI is calculated correctly.”

Copilot reviews:

• the measure
• the logic
• filters
• dependencies
• model coherence
• business semantics

And returns:

• validation
• explanation
• recommendation

This is invaluable for functional consultants.

To conclude

Copilot is not an add‑on to Power BI.

It is a new layer of intelligence built on top of the semantic model, transforming how functional professionals interact with data.

For the first time, a functional consultant can:

• validate KPIs without writing DAX,
• generate complete report pages without manual design,
• obtain executive narratives without drafting them,
• uncover insights without relying on technical analysts,
• and explain complex metrics with clarity and business context. 

This does not eliminate the technical role. It enhances it.

And it opens a new space for functional professionals: the augmented analyst, capable of connecting business, data and decisions with unprecedented speed.

Copilot turns Power BI into conversation.

And it places functional roles at the centre of modern analytics.

Part 4 will explore how Copilot transforms documentation, governance and data lineage within Fabric — and how this directly impacts real Dynamics 365 and Business Central projects.

Continuation of the series “The Evolving Functional Role in Microsoft Fabric” (Part 2 of 5)

Previously, we uncovered how Copilot reshapes the functional landscape. Today, we step into the engine room of Fabric… where data engineering becomes accessible to everyone.

1. Copilot in Data Factory: Transforming Data Without Writing Code

Data Factory has always been powerful—but technically demanding. Copilot introduces a functional layer that allows professionals to:

• generate transformations,
• clean and prepare data,
• adjust column logic,
• explain each step,
• validate business rules,
• detect inconsistencies.

All without writing a single line of code.

Functional example

An analyst needs to classify customers by age. Before: they relied entirely on an engineer. Now they ask Copilot:

“Create an AgeRange column with business‑defined age categories.”

Copilot generates the transformation and explains the logic. The analyst reviews and approves it confidently.

Functional value

• Reduces dependency on technical teams.
• Accelerates decision‑making.
• Ensures business rules are applied correctly.
• Improves data quality from the functional side.

2. Copilot in Pipelines: Understanding Data Flows Without Engineering Skills

Pipelines are the backbone of data movement. Copilot enables functional roles to:

• generate activities,
• add steps,
• request summaries,
• understand source and destination,
• detect errors,
• validate flow logic.

Functional example

A consultant needs to confirm whether a pipeline is moving data correctly. Before: they waited for a technical explanation. Now they ask Copilot:

“Summarise this pipeline and explain its source and destination.”

Copilot returns:

• source,
• destination,
• table,
• activity purpose,
• dependencies.

No JSON. No logs. No engineering jargon.

Functional value

• Enables functional auditing of data processes.
• Improves communication between business and engineering.
• Reduces misunderstandings in data flows.
• Increases autonomy and clarity.

3. Copilot as a Bridge Between Business Logic and Technical Execution

Copilot does not replace engineers—it enhances collaboration.

Functional professionals can now:

• validate business rules,
• review transformations,
• understand flow logic,
• detect anomalies,
• request adjustments,
• document processes.

Functional example

A consultant notices duplicated records in a dataset. Before: they waited for engineering analysis. Now they ask Copilot:

“Explain why this activity might be producing duplicates.”

Copilot identifies potential causes:

• missing primary key,
• incorrect join,
• lack of filtering,
• transformation error.

The consultant enters the meeting informed and prepared.

4. Copilot as a Functional Documentation Tool

• Copilot can generate:
• summaries,
• descriptions,
• step‑by‑step logic,
• transformation explanations,
• dependency maps.

This turns Copilot into a functional documentation engine.

Functional example

A consultant must document a pipeline for a client. Before: they relied on engineers to describe each step. Now Copilot produces:

«This pipeline copies data from Azure SQL to Lakehouse, applying filters and transformations based on defined parameters.”

The consultant simply refines the wording for the client.

5. What This Means for Functional Roles

Copilot empowers functional professionals to:

• understand complex data processes,
• validate business logic,
• detect errors early,
• request precise changes,
• document flows clearly,
• participate in data engineering,
• reduce analysis time,
• improve data quality.

All without writing code. All without losing control of the process.

To conclude

Copilot democratises data engineering. It enables analysts and consultants to engage directly with data preparation, movement and validation. Fabric is no longer a purely technical platform—it is a collaborative environment where business roles act with autonomy, clarity and speed.

And the story deepens…

Microsoft Fabric introduces a fundamental shift in how functional teams interact with data, analytics and decision‑making. Copilot is not merely an AI assistant; it is a new operating model for business users, analysts and consultants who work with data every day.

For years, functional roles relied heavily on technical specialists to transform data, validate models or build reports. Fabric changes that dynamic. Copilot empowers functional professionals to participate directly in the data value chain — without needing deep technical expertise.

1. Functional roles now participate in data engineering

Copilot enables functional roles to:

• generate transformations,
• clean and prepare data,
• create pipelines,
• explain code,
• detect errors,
• validate flows.

All without needing to write Spark, SQL or DAX.

Functional example

An analyst notices inconsistent values in the “CustomerSegment” field. Previously: they opened a ticket and waited. Now: they ask Copilot to review the transformation and identify where the inconsistency originates. The engineer steps in only for the final correction.

2. The functional consultant becomes a designer of context

Copilot works through context, not magic. This means functional consultants must now:

• guide how questions are formulated,
• define clear instructions,
• validate Copilot’s responses,
• understand token processing and consumption,
• design prompts for Fabric Data Agents,
• translate business processes into natural‑language queries.

Functional example

A manager asks:

“How is the campaign performing?”

Copilot returns a vague answer. The functional consultant reframes the question:

“Compare conversions and cost per channel for Campaign X over the last quarter.”

The insight becomes precise and actionable.

3. Power BI evolves from reporting to conversation

Copilot transforms Power BI into a conversational analytics tool where:

• users ask questions,
• reports respond,
• functional consultants guide the interaction,
• semantic models become a shared language.

Functional example

A finance director asks:

“What is the EBITDA variance by region over the last six months?”

Copilot produces:

• a visual,
• a narrative summary,
• an explanation of the trend.

The functional consultant ensures the semantic model supports the question correctly.

4. Fabric Data Agents: the biggest functional leap

ºFabric Data Agents allow any user to:

• ask questions in natural language,
• receive contextual answers,
• without opening Power BI,
• without SQL,
• without DAX.

Functional consultants design:

• instructions,
• examples,
• constraints,
• tone,
• user experience.

Functional example

An operations manager asks:

“Which plant had the most production delays this month?”

The agent responds with:

• a table,
• a chart,
• a contextual explanation,
• an additional insight.

5. Functional roles must now understand cost, capacity and consumption

Fabric introduces a new concept: cost per token.

Functional professionals must now:

• recommend when Copilot should be used,
• avoid unnecessary prompts,
• optimise consumption,
• understand capacity strategies,
• advise on scaling decisions.

Functional example

A team uses Copilot to generate long, complex SQL queries. Consumption spikes. The functional consultant recommends:

• shorter prompts,
• splitting questions,
• using Data Agents for repetitive queries.

To conclude

Fabric does not simply modernise technology. It reshapes how functional roles work with data, insights and decision‑making.

Copilot turns functional professionals into:

• context designers,
• question architects,
• decision facilitators,
• insight enablers.

This is the new functional landscape in Microsoft Fabric — one where business users and consultants play a central role in the analytical process.

Poor functional decisions in Business Central SaaS rarely show their impact on the day they are made.

They show up later—when the system is already in production, users depend on it, and correcting the damage costs far more than doing things properly from the start.

This is not a technical post.

It is a practical reflection on how small functional choices can create large operational, financial and organisational consequences.

1. When a functional change looks small… but isn’t

Some decisions seem harmless:

• enabling a setting,
• adjusting a parameter,
• adding a field,
• modifying a workflow,
• allowing an exception “just this once”.

Business Central does not forgive improvisation.

Real case

A retail company enabled bin tracking because “the warehouse manager wanted more control”. No impact assessment. No process review. No sandbox testing.

Three weeks later:

• picking slowed down,
• warehouse staff were confused,
• orders were delayed,
• inventory became unreliable,
• finance received inconsistent valuations.

The hidden cost wasn’t the configuration. It was lost productivity, frustrated staff, and a decline in service quality.

A junior consultant sees the screen. A senior consultant sees the consequences.

2. The cost of creating data without purpose

Business Central makes it easy to create fields, tables and automations. But ease can become a trap.

Real case

A team created custom fields to “improve sales control”. No one defined:

• who would use them,
• what they were for,
• how they would be validated,
• which process supported them,
• how they affected reporting.

Result:

• inconsistent reports,
• duplicated data,
• decisions based on incomplete information,
• internal debates about “which number is correct”.

The hidden cost wasn’t the field. It was the loss of trust in the ERP.

A junior consultant creates fields. A senior consultant avoids them.

3. The cost of misunderstanding accounting impact

Functional decisions always end up in finance. Always.

Real case

A user changed VAT settings because “a supplier asked for it”. No impact review. No historical analysis. No validation with accounting.

Result:

• incorrect entries,
• inconsistent tax reports,
• blocked internal audits,
• months of corrections.

The hidden cost wasn’t the change. It was the correction, the audit, the wasted time, and the compliance exposure.

A junior consultant looks at the screen. A senior consultant thinks about month-end closing.

4. The cost of allowing functional exceptions

Exceptions feel convenient. Until they destroy the system.

Real case

A client asked to post a purchase invoice without a purchase order “just this once”. It was allowed. Then it happened again. And again. And again.

Three months later:

• purchasing control disappeared,
• cost reports didn’t match,
• margins became impossible to calculate,
• the ERP stopped reflecting reality.

The hidden cost was the loss of operational discipline.

A junior consultant says “yes”. A senior consultant says “no—and explains why”.

5. The cost of not thinking ahead

A functional decision is never for today. It is for six months from now.

Real case

A company customised its approval workflow because “that’s how we do it in Excel”. It worked. But six months later they wanted:

• automated purchasing,
• supplier integration,
• Power Automate flows,
• mobile approvals.

The customisation blocked everything. The workflow had to be rebuilt from scratch.

The hidden cost was functional debt.

A junior consultant thinks about the current need. A senior consultant thinks about the future of the business.

To Conclude

Poor functional decisions don’t break the system immediately. They break it slowly—through frustration, rework, inconsistencies, and operational noise.

Business Central SaaS doesn’t fail because of technology. It fails because of functional decisions made without criteria.

The hidden cost of a poor functional decision is:

• time,
• money,
• frustration,
• loss of trust,
• loss of control,
• loss of operational quality.

A junior consultant configures. A senior consultant is responsible for planning for the future and handling updates.

Functional governance in Business Central SaaS is not an abstract concept: it is the discipline that ensures the ERP evolves in an orderly, sustainable manner that is aligned with the business.
Without governance, Business Central becomes a collection of patches.
With governance, it becomes a living platform that drives decisions.

Functional governance in Business Central SaaS is not an abstract concept: it is the discipline that ensures the ERP evolves in an orderly, sustainable manner that is aligned with the business.
Without governance, Business Central becomes a collection of patches.
With governance, it becomes a living platform that drives decisions.

1. What functional governance really means in Business Central SaaS

It is the framework that guides how processes are designed, how changes are approved, how responsibilities are assigned and how the ERP evolves over time.
Good governance answers questions such as:

• What is the business impact of this change?
• What is the ERP impact?
• Who approves it?
• How is it documented?
• How is it measured?
• How does it affect future scalability?

Governance is the invisible architecture that keeps Business Central healthy.

2. Real examples (practical cases)

✔ Case 1: Inventory configuration changes

Without governance:

• valuation inconsistencies,
• accounting discrepancies,
• blocked internal audits.

With governance:

• impact assessment,
• sandbox testing,
• documentation,
• committee approval,
• controlled deployment.

✔ Case 2: Proliferation of custom fields

Without governance:

• duplicated data,
• reporting confusion,
• uncontrolled growth of customisations.

With governance:

• validation of need,
• review of standard functionality,
• ownership assignment,
• usage policy.

✔ Case 3: Financial processes

Without governance:

• inconsistent month‑end closing,
• unclear roles,
• hidden dependencies.

With governance:

• RACI matrix,
• closing checklist,
• defined functional roles,
• smoother internal audits.

3. How to measure functional governance (real tools and KPIs)

✔ Key functional indicators

• % of documented processes
• % of changes approved through governance
• Number of incidents caused by misconfiguration
• Number of functional exceptions
• Adoption time for new features
• Ratio of standard vs customised processes

✔ Tools that support governance

• Azure DevOps – change control, approvals, backlog
• SharePoint – functional documentation repository
• Power BI – adoption and usage dashboards
• Copilot Studio – automated functional queries
• Sandbox environments – controlled testing before deployment

4. Adoption: the real thermometer of governance

Governance is not measured in documents.
It is measured in user behaviour:

• Do users follow the designed process?
• Do they avoid shortcuts?
• Do they understand the impact of their decisions?
• Do they participate in functional committees?
• Do they request changes with proper criteria?

A well‑governed ERP has mature users, not just trained users.

5. My experience as a Functional Consultant and MCT

Across projects, I see the same pattern:
The organisations that succeed with Business Central SaaS are not the ones that customise the most, but the ones that govern the best.

Functional governance is:
clarity, responsibility, sustainability and evolution.

It is the bridge between technology and business decision‑making.

To Conclude

Business Central SaaS does not need more customisations.
It needs stronger governance.

Let’s keep building value.

Public sector organisations face increasing pressure to demonstrate transparency, traceability and disciplined administrative processes. In this context, Microsoft Dynamics 365 Business Central SaaS has evolved into more than an ERP: it has become a platform that strengthens governance, ensures data integrity and supports continuous auditability across the entire administrative cycle.

In my experience implementing Business Central for public sector bodies and state‑owned companies, I have seen how the system can address complex administrative scenarios by relying primarily on its native standard functionality, complemented only by functional extensions when legislation or operational casuistry requires it. The objective has never been to override the standard, but to extend it without breaking native flows, preserving the ERP’s architecture and ensuring full traceability.

1. Continuous auditability and full administrative traceability

Public sector entities operate under permanent oversight. Every approval, modification and budgetary movement must be traceable and verifiable.

Business Central provides:

• detailed logging of critical events,
• real‑time user action tracking,
• automatic evidence generation for audits,
• telemetry‑based anomaly detection.

In my experience, standard approval workflows and change logs allow complete audit trails without complex development. Every action is recorded: who approved, what changed, when it occurred and under which permissions. This supports internal auditors, financial controllers and oversight bodies.

2. Case management: standard as the foundation, extensions as the regulatory layer

Case and dossier management is central to public sector operations. Business Central structures cases using:

• related documents,
• native approvals,
• versioning,
• change logs,
• standard workflow orchestration.

In my experience, complex case scenarios have been resolved by relying on the standard and adding functional extensions only when legislation requires additional validations, specific spending controls, restrictions based on service type or multi‑level approval chains.
Extensions are functional, non‑invasive and always respect native flows to maintain auditability and data integrity.

3. Minor and major contracts: operational control without breaking the standard

Contract management is one of the most regulated processes in the public sector. Business Central supports:

• minor contracts,
• major contracts,
• renewals,
• spending limits,
• budget linkage,
• approvals based on thresholds.

In my experience, the standard covers most scenarios—requests, approvals, execution and budget control. When specific regulatory rules apply, functional extensions have been added to ensure compliance, full traceability, data integrity and audit‑ready evidence.
The standard remains the foundation; extensions simply add the regulatory layer.

4. Procurement and tendering: transparency and control through native flows

Public procurement demands complete transparency. Business Central structures tendering processes using:

• standard purchasing flows,
• native approvals,
• role‑based access control,
• decision logging,
• budget integration,
• tender dossier tracking.

In my experience, complex tendering scenarios have been resolved through standard approvals, related documents, change logs and telemetry. Where legislation requires additional steps, functional extensions have been added to support specific tender phases, adjudication controls, operational restrictions and additional evidence for oversight bodies.
The native flow remains intact; the extension adds the administrative requirements.

5. Governance and operational discipline

One of the biggest challenges in the public sector is process heterogeneity: Excel‑based workflows, manual approvals and operations dependent on individuals rather than systems.

Business Central promotes governance by:

• standardising processes,
• automating validations,
• controlling approvals,
• reducing human error,
• enabling fiscalisable operations.

In my experience, adopting the standard has transformed entire departments, replacing manual processes with structured, auditable flows. Functional extensions have been applied only when necessary, ensuring compliance without compromising the ERP’s architecture.

To Conclude

Public sector organisations require systems that guarantee control, transparency and continuous auditability. Business Central has proven capable of meeting these demands with rigour, traceability and operational discipline.

In my experience, the combination of standard functionality, well‑designed functional extensions, native ERP processes and a modern SaaS architecture allows public sector entities to adopt a more mature, auditable and integrity‑driven operational model.

Business Central is not just an ERP:
it is a public governance system.

1. The traditional ERP is obsolete: modern companies need intelligence

For decades, ERPs were designed to record.
Today, organisations require systems that interpret, alert, predict, prove and guide users to operate better.

Business Central evolves into an intelligence system because it integrates capabilities that were previously fragmented:

• Advanced fiscal automation.
• Governance and audit APIs.
• Embedded analytics and traceability.
• Multi‑country localisation.
• User experience designed for adoption.
• Shorter processes and reduced operational friction.

This turns the ERP into a corporate control centre, not merely a financial system.

2. Fiscal intelligence: faster decisions and lower risk

Based on the official update:
Fiscal automation

Business Central now:

• Calculates tax withholdings automatically based on supplier, country and transaction type.
• Applies accelerated depreciation according to fiscal regulations.
• Reduces manual errors and review time.
• Enables simulation of investment and return scenarios.

Real value for the organisation

• CFO: faster decisions and reduced regulatory risk.
• CEO: frictionless expansion.
• Auditor: automated, traceable evidence.
• Business owner: protection of capital and cash flow.
• End user: fewer manual calculations, fewer errors, less operational stress.

3. Internal control intelligence: evidence that previously did not exist

Based on the official links:

• APIs for analysing permissions
• APIs for analysing approval workflows

These APIs expose critical information that was previously hidden:

• Who can approve payments.
• Who can modify master data.
• Which approval workflows are active or inactive.
• Which sensitive configurations have changed.
• Which users hold permissions misaligned with their role.

Real value for the organisation

• CIO: independence from the partner and control of technological risk.
• Internal auditor: segregation‑of‑duties tests based on evidence.
• CEO: real governance, not declarative governance.
• CFO: financial control without blind spots.
• End user: clarity of role, fewer blockages, less “consultant dependency”.

4. Operational intelligence: fewer clicks, more decisions

Business Central incorporates improvements that reduce operational friction:

• Shorter processes.
• Cleaner, more intuitive screens.
• Automation of repetitive tasks.
• Integration with Power BI and Copilot.

Real value for the organisation

• Faster teams.
• Cleaner data.
• More reliable decisions.
• Less dependence on individual knowledge.
• More autonomous end users, with reduced need for support.

5. Multi‑country intelligence: expansion without complexity

The update includes enhancements in:

• Electronic invoicing.
• Regulatory reporting.
• Advanced localisation.
• International compliance.

Real value for the organisation

• CEO: expansion without multiplying complexity.
• CFO: consistent compliance across jurisdictions.
• Auditor: consolidated, traceable evidence.
• End user: standardised processes, fewer variations, fewer errors.

6. Executive intelligence: decisions based on evidence

When an ERP:

• automates fiscal processes,
• exposes permissions,
• reveals traceability,
• integrates analytics,
• reduces operational friction,
• and accelerates adoption…

…it stops being a transactional system and becomes a corporate decision engine.

Real value for the organisation

• Less intuition.
• More evidence.
• Lower risk.
• Higher speed.
• Less partner dependency.
• Stronger governance.
• More competent and productive end users.

7. End‑user adoption: the component that turns intelligence into results

This is the missing piece that delivers real value to companies.

Business Central introduces improvements that directly impact adoption:

✔ Cleaner interfaces

Less visual noise, less confusion, more speed.

✔ Guided processes

Users understand what to do without relying on consultants.

✔ Fewer clicks

Fewer steps = fewer errors = higher productivity.

✔ Copilot integration

Contextual assistance, not generic help.

✔ Process standardisation

Fewer departmental variations, more consistency.

✔ Reduced dependence on individual knowledge

The system guides — not the user’s memory.

Real value for the organisation

• Lower staff turnover.
• Reduced learning curve.
• Less internal support.
• Higher productivity.
• Better data quality.
• Faster operations.
• Greater confidence in the system.

To Conclude

Business Central is no longer an ERP.
It is an enterprise intelligence system that:

• anticipates risks,
• automates compliance,
• exposes control evidence,
• accelerates decisions,
• facilitates adoption,
• and supports international expansion.

Companies that understand this do not only operate better:
they lead better, control better and grow better.

1. The structural problem: an ERP that is used, but not governed

In most organisations, the ERP is the operational core — yet its internal control model is largely opaque:

• Legacy roles inherited from old implementations.
• Excessive permissions granted “to avoid blocking operations”.
• Approval workflows that no one has reviewed in years.
• Audit processes based on screenshots, Excel exports and verbal explanations.

The company operates — but cannot demonstrate that it operates under control.

Microsoft’s new APIs directly address this governance gap by turning what used to be hidden configuration into queryable, analysable and repeatable evidence.

2. APIs for analysing permissions: evidence of who can do what

Based on: Use new APIs for analysing permissions for auditors and IT staff

Utilizar nuevas APIs para analizar permisos para auditores y personal de TI | Microsoft Learn

These APIs allow organisations to extract, in a structured and automated way:

• Which users have access to which objects.
• Which roles are assigned to each user.
• The effective permissions resulting from combined roles.
• Which users hold high‑risk privileges (e.g., modifying vendors, approving payments, changing financial parameters).

Concrete example for a CEO or business owner

A permissions report generated through these APIs can answer questions such as:

• “How many users can modify the chart of accounts?”
• “Who can create vendors and also approve payments?”
• “Which users hold permissions that do not match their actual job role?”

This enables the detection of:

• Internal fraud risks.
• Excessive privilege assignments.
• Poorly designed roles.
• Permissions inherited from former employees or consultants.

Business value

• For a CEO: real control over who can touch critical parts of the business.
• For a CIO: independence from the partner and a clear map of risk.
• For auditors: verifiable, repeatable evidence instead of ad hoc explanations.

3. APIs for analysing approval workflows: traceability of the control process

Based on: Use new APIs for analysing approval workflows for auditors and IT staff

Utilizar nuevas APIs para analizar los flujos de trabajo de aprobación de auditores y personal de TI | Microsoft Learn

These APIs allow organisations to review:

• Which approval workflows exist in the system.
• Which conditions trigger each workflow.
• Which users or groups approve each document type.
• Approval limits and escalation rules.
• Which workflows are active, inactive or misconfigured.

Concrete example for a CFO or auditor

Using these APIs, a CFO or internal auditor can identify:

• Approval workflows that never execute, indicating potential bypass.
• Users with approval limits far above their organisational role.
• Documents that should be approved but are not passing through any workflow.
• Recent changes to approval rules that may weaken financial control.

Business value

• For a CFO: stronger assurance that money does not move without proper oversight.
• For internal audit: full traceability of the approval chain.
• For business owners: protection of cash, assets and reputation.

4. What changes for senior leadership

These APIs are not a minor technical enhancement; they represent a governance shift.

Before

• Dependence on the partner for critical information.
• Manual, slow and inconsistent audit processes.
• Roles and workflows left unreviewed for years.
• Hidden operational and fraud risks.

Now

• Structured, automatable evidence of permissions and approvals.
• Continuous review of the ERP’s control model.
• Integration with Power BI, GRC tools and internal dashboards.
• Governance based on data, not assumptions or trust alone.

For CEOs, CIOs and CFOs, this means the ERP can finally be treated as part of the formal governance architecture, not just as an operational system.

5. What CEOs, CIOs and auditors should do next

For CEOs and business owners

• Request a full effective permissions report using the new APIs.
• Review who can approve payments and modify master data.
• Demand a risk map of the ERP that highlights high‑risk roles and workflows.

For CIOs

• Integrate these APIs into IT and governance dashboards.
• Automate alerts for changes in critical roles or approval rules.
• Establish quarterly ERP governance reviews with Finance and Audit.

For internal audit

• Incorporate these APIs into the annual audit plan.
• Define standard segregation‑of‑duties tests based on permissions data.
• Monitor changes in approval workflows as part of continuous auditing.

6. To Conclude: from ERP usage to ERP governance

The real transformation here is conceptual:

• Business Central stops being merely “the system where transactions are recorded” and becomes a source of structured governance evidence.
• Senior leadership gains the ability to measure and demonstrate control, rather than simply assuming it.
• Auditors and IT teams can move from manual, reactive checks to systematic, proactive and data‑driven oversight.

In practical terms:

• Organisations can quantify their segregation of duties.
• They can trace changes in critical configuration.
• They can prove, not just claim, that their ERP is aligned with their internal control framework.

For CEOs, CIOs, CFOs and business owners, this is the difference between trusting that the ERP is under control and knowing — with evidence — that it is.