AI agents
Enterprise
Business Process Solutions in Microsoft Fabric
I set a readiness-first design direction for Business Process Solutions, the first Microsoft first-party workload on Fabric to reach GA, and gave the team its first shared adoption baseline: about half of active items had no data source connected.
My part
Design strategy, agent demo, advisory-board research, telemetry
Duration
Mid 2026 – now
Crew
SAP and Oracle PM, engineering, research
Ships on
Microsoft Fabric · Microsoft 365
Context & role
Business Process Solutions (BPS) is a native Microsoft Fabric workload that brings SAP data, and sources such as Salesforce, into prebuilt data models, automated extraction, Power BI reports and the semantic layer that Fabric data agents build on. It entered private preview in September 2025, public preview in December 2025 and general availability in October 2026. Its users rarely share a job: an SAP admin connects source systems, a data analyst wants trusted SAP semantics, a business user wants to know why a payment is late, and a security owner wants to know which agents can touch SAP. My role: I joined in mid-2026 as the designer embedded with the SAP and Oracle product teams, building on foundational research done before I arrived. I owned the agent demo, the advisory-board session design and synthesis, the telemetry tracker and the design strategy; the GA itself was a PM and engineering result.
Stakes
Business Process Solutions brings SAP data, and sources such as Salesforce, into prebuilt data models, Power BI reports and the semantic layer that Fabric data agents build on. The pitch was SAP analytics in two weeks instead of six months, and more than 100 customers piloted it. Usage told a different story: many instances never produced an insight, setup stalled at connecting a source system, and configuring one often took a day or more. Every stalled instance is a customer who did the setup work and never saw the payoff, and an agent can't explain a late payment if the payment data never arrived.
Reframe
Asked: better reports, onboarding and an agent. Reframed: an activation problem.
The work I inherited was framed around surfaces. Putting the usage data next to customer feedback showed the top problem was activation, not acquisition, and customers were stitching files and capabilities together across Fabric, Foundry and Microsoft 365. I reframed the question from "how should the agent look" to "how does a customer get from SAP data to a trusted decision, and see where that path breaks." A useful experience had to answer five questions before any agent did: Is my data ready? What is missing or failing? What business meaning has been applied? What can I confidently analyze? What should I do next?
Illustration: from three product surfaces customers had to stitch together, to one job spine where each step shows its health.
Evidence
Telemetry and an advisory board, read with their limits
I used three sources and was explicit about what each couldn't tell us. A usage analysis showed where setup stalled. I designed the customer advisory board's AI-agents session as a learning conversation rather than a feature vote: customers mapped one real workflow from trigger to verification and set an autonomy boundary for each action (answer, recommend, prepare or execute). The polls were small, so I labeled every result with its sample; extraction was the top data blocker and access control the top security concern. Then I built a telemetry tracker with exact metric definitions. Every source pointed the same way: data readiness, not dashboards or agents, was the first barrier.
01
Activation, not acquisition. Customers signed up; many never reached their first insight.
02
Connecting data is where it breaks. Setup stalled at connecting a source system more than anywhere else.
03
Demand shifts with framing. Supply chain led when customers spoke unprompted; finance led when we showed scenarios.
Key decision
Data readiness before agents
I was shaping three plans: data analytics, the operational AI agent and security. The obvious option was to run them in parallel and lead with the agent, the most visible part of the story; another was to pick the agent delivery model from a close advisory-board poll. I recommended neither and sequenced the work by dependency: a Health and Operations View first, so customers can see whether their data is ready; then a thin agent pilot on real customer data, gated on green health checks; then a trust layer. The delivery model gets settled by a "same scenario, two packages" test, not a poll. I chose a readiness-first sequence over parallel roadmaps because an agent on bad data loses trust fast, accepting that the agent pilot waits several months.
Second call
Design how much the agent may do, not just how it looks
For an agent that writes to SAP, the important decisions are about permission, not layout. In the advisory-board session I asked customers to set an autonomy boundary for each action in a real workflow: answer, recommend, prepare or execute. I made that scale the backbone of the agent design: every agent action sits on it, and changing a business record requires a human approval step. I chose explicit autonomy levels over a single on/off agent switch because customers' comfort varied by action, accepting a more complex permission model. The agent pilot will track human overrides, wrong actions and time saved, so trust is measured rather than assumed.
Illustration: the three plans on the table, and why the work was sequenced by dependency.
Craft
A demo that runs the whole job, in order
I built the BPS Agent Demo with an engineer so it opened with starter prompts for the core scenarios, and created demo data for cases such as delayed payments, so the team could show an agent explaining a late payment rather than describe one. The walkthrough runs the jobs in order: a Power BI report, a read-only Fabric data agent answering a revenue question, and a Microsoft 365 business operations agent that looks up and edits an SAP customer record. The planned Health and Operations View drills from overall health to source system, dataset and each data stage, so a failure has a visible place and a next step.
Illustration: every agent action sits on an autonomy scale, and changing a record needs a person's approval.
System
An evidence ladder that turns signals into decisions
The deeper gap was organizational: a customer signal was usually interpreted internally and turned into a feature before customers ever reacted. I proposed a repeatable loop (signal, hypothesis, evidence, opportunity, concept, customer validation, recommendation) with an evidence ladder that raises the bar as investment grows. Each rung is scored on four questions: does the problem repeat, is BPS uniquely placed, can customers deploy the answer, and can we measure the change? Underneath sit a job spine (connect, prepare, consume, act and govern) that gives PM, engineering and customers one flow to react to, and a trust model, Discover, Control, Approve and Audit, that structures the security plan.
Illustration: the evidence ladder raises the bar as investment grows; the trust model sits underneath.
What shipped
What we built toward GA
By GA the team had a native Fabric workload with prebuilt SAP data models, automated extraction, Power BI reports and the semantic layer agents build on. My work shaped what comes next and how it will be judged: a dependency-ordered plan with a Health and Operations View first, so customers can see whether each stage of their data is ready; a thin agent pilot on real customer data, gated on green health checks; and a trust layer built on Discover, Control, Approve and Audit. Underneath sits a shared telemetry tracker with exact definitions and values at public preview, GA sign-off and after, plus a drafted research program: a baseline outcomes survey, discovery interviews across seven roles and a sizing survey.
Outcome
What changed
BPS reached general availability in October 2026 with more than 100 customers onboarded; that is a team result. What I added is a shared baseline with exact definitions and goals, such as halving active items with no source system, plus a jobs-by-role model, a dependency-ordered plan and a drafted research program. I also built the agent demo that walks the whole path in customer-job order, with every agent action on an autonomy scale and a human approval step before an SAP record changes. The health view and agent pilot are proposals, not shipped features. No business metric has moved yet; what changed is that the team can now tell whether one does.
Reflection
Measure first, and recruit the people who can say no
I would set the baseline before designing anything; the tracker came late, so early concepts were judged on internal enthusiasm. I would recruit security buyers on purpose, because the advisory board leaned toward data roles even though access control was the top concern. And I would test on customer data sooner: demo data shows an agent story, not whether someone trusts an answer about their own payments. The principle I took away: treat a launch as the start of measurement, and order the work by what it depends on, not by what demos best.
