Hello, my name is Milco Peters and I translate how technology actually shapes business reality.
Contoso now has clean dataverse tables, structured employee records, vacation requests, approval
states and country rules, but none of that fixes the real problem yet because people still
can't work through the process in a way that changes behavior.
Data on its own is only stored in tent, it's not execution.
And this is where most first power platform projects either create momentum or quietly
stall.
In this episode, we move from structure to interaction and I'll show you how one decision
canvas or model driven shapes adoption, licensing, governance and how fast a vacation request
moves from someone's head into an actual business outcome.
The moment data stops being enough, so let's step into Contoso for a second.
Up to this point, they've done something a lot of organizations never do properly.
They created structure first.
Employee data is in dataverse, vacation requests have a place to live.
Approval status is no longer a vague phrase inside someone's inbox.
Country rules exist as data instead of tribal memory.
On paper, that sounds like progress and it is.
But only in the same way a well-organized warehouse is progress before the delivery trucks start
moving.
Because if you look closely, the operating pain is still there.
An employee still wants time off and still starts with the easiest available path, which
is usually an email, a team's message or some half-verbal agreement with a manager.
The manager still has to remember what was agreed.
HR still ends up checking spreadsheets, inbox threads and local policy notes to work out
what is actually true.
So yes, the data model is cleaner.
But the day-to-day business reality has not changed yet because the people inside the process
are still interacting with the old front door.
And why is that?
Because stored data and enacted process are not the same thing.
We mix those up all the time.
We think that once a table exists, the business is somehow more mature.
But maturity does not come from storage.
It comes from repeatable behavior.
It comes from making the right action easier than the wrong one.
That is the gap most teams miss.
They celebrate that they now have the data, but what they really have is an inventory of
decisions not yet taken.
The employee has not submitted the request through a governed path.
The manager has not approved anything through a visible mechanism.
HR has not gained operational clarity just because a dataverse table is ready.
Until someone can enter, review and move work through a usable interface, the system is
structurally incomplete.
It's not a people problem.
It's a system outcome.
The people are using email because email still behaves like the path of least resistance.
And the system is doing exactly what it was shaped to do.
That captures data well enough for architects and admins to feel progress, but it does not
yet change the human experience at the point where the request enters the business.
This clicked for me years ago when I watched teams proudly present a new data model and
then act surprised that adoption stayed flat.
They had solved storage but not interaction.
In technical terms, they had a back end.
In business terms, they still had friction.
And friction always finds a workaround.
Now map that to vacation requests.
The employee's real job is simple.
I need time off.
I need to know who sees this.
I need confidence that it won't disappear into someone's calendar chaos.
The manager's job is also simple.
Is this valid?
Does it fit the team context?
And who covers if I'm away?
HR needs something else again.
Consistency, visibility, a clean record, less chasing.
None of those jobs are solved by tables alone.
Tables matter because they give us structure, status, relationships and future reporting.
They are the backbone, but nobody experiences a backbone directly.
What they experience is the front door.
They experience whether the process feels clear, fast and trustworthy or vague, slow and
social.
That is why the first app matters so much.
Not because it proves power apps can render screens.
Not because it gives leadership something shiny to demo.
It matters because it is the first moment where the business stops asking, do we have the
data?
And starts asking, can people actually work through this in a better way?
Once you see that gap, the next question changes.
It is no longer, can we build an app?
Of course we can.
The real question is, what kind of app are we actually building and what operating behavior
are we trying to create?
The real job of a first app.
So before we talk about screens, controls or whether canvas feels easier than model driven,
we need one clean reframing.
The first app is not a feature demo.
It is a business interface.
And that difference changes almost every decision that comes after it because when teams
treat the first app like a demo, they optimize for what looks impressive in a workshop.
When they treat it like a business interface, they optimize for what removes friction at
the exact point where work enters the system and starts moving.
That is the real job.
In Contoso, nobody wakes up wanting a power app.
That is not the need.
The need is much simpler and much more operational.
An employee wants to ask for time off.
A manager wants to review that request without hunting for context.
HR wants to know what is pending, what is approved and where the process is stuck.
So the app is not the product.
The app is the door through which that operational behavior becomes consistent.
And why does that matter so much?
Because first apps teach the organization what low code means.
If the first app feels bloated, confusing or overbuilt, people conclude the platform is
messy.
If the first app is clear, fast and trustworthy, people conclude the platform can
reduce friction in real work.
Same technology, different lessons, different business outcome.
This is where most people miss the split between the human job and the system job.
The human job in a vacation request process is very small.
Ask, review, approve, track.
That is it.
But the system job is not small at all.
The system has to validate the submission.
It has to root the request into the correct path.
It has to record status changes in a way that stays visible and auditable.
And it has to expose enough status back to the employee, manager and HR team.
So nobody is forced back into site channel communication just to understand what is happening.
So when we design the first app, we are not building around every system responsibility
at once.
We are deciding where the human interaction should be simple and where the underlying structure
should carry the weight instead.
That distinction protects us.
Because the first release should narrow scope, not prove everything the platform can do.
A lot of teams try to use the first app as a stage for every capability they have just
learned.
Tabs everywhere.
Conditional logic everywhere.
It feels because they might be useful later, but that approach creates structural drag
before trust has even formed.
A first app earns trust by being small enough to succeed.
At Contoso, success does not mean we digitize leave management in some giant abstract sense.
Success means something much more grounded.
An employee can submit a request in one clear place.
A manager can see it without inbox archaeology.
HR can track status without chasing people.
And the cycle time starts dropping because the request no longer enters the business as
an unstructured message.
That is the threshold.
Once you nail that, everything else clicks.
Because now the app is doing what a first app should do.
It reduces friction at the point where decisions enter the system.
It makes the process more visible than memory.
And it starts replacing social guesswork with operational clarity.
The reason this works is simple.
People trust processes they can see.
They avoid processes that feel ambiguous.
So the first app should not try to look advanced.
It should try to make the next action obvious and the current status legible.
That is where the value comes from.
Not from animation, not from complexity, not from showing the full future architecture on day one.
From reducing the cost of doing the right thing.
And once you understand that, another point becomes obvious.
The wrong first app does not just fail quietly.
It teaches the organization the wrong lesson.
It tells people low code creates clutter.
That forms create overhead.
And that structured processes are slower than informal ones.
From a system perspective, that is not just disappointing.
It is expensive because now your next app starts from distrust.
So before we choose canvas or model driven, we need one clean definition of the problem
we are actually solving.
Why first apps fail before anyone opens them?
Most first apps fail long before a user taps the icon because the failure usually starts
in the design conversation, not in the release itself.
The team begins with screens.
Someone sketches a homepage.
Someone else asks for tabs.
A manager wants a dashboard and HR wants every exception visible from day one.
The app starts taking shape as a collection of requests.
But no one has yet defined what the system is supposed to change.
That sequence sounds normal.
It is also where the drag begins.
Because if you start with screens, you usually copy the old process into a new interface.
The email form becomes a digital form.
The spreadsheet columns become fields.
The approval confusion becomes a drop down.
It looks more modern, but the operating behavior stays the same.
People still carry interpretation in their heads.
They still work around ambiguity.
They still compensate for a weak process through extra messages inside conversations.
So the app looks cleaner, but the business does not move faster.
I see this all the time.
Teams call it digitization when what they really built is a better looking version of the
same structural problem.
They rebuild friction in a nicer font.
And then they wonder why adoption is hesitant, why support questions pile up, and why nobody
trusts the status field enough to stop sending follow-up emails.
The reason is simple.
They never define system intent.
System intent is the answer to a very plain question.
What should happen for whom under what conditions and what should become visible the moment
that action enters the business?
If that is not clear, the app has no stable center.
It becomes a surface for collecting wishes.
And once that starts, overdesign takes over.
A leader asks, what if the employee wants half days in one country and carry over in another?
Someone else asks, what if the manager is absent for two weeks?
HR asks for attachments, comments, override paths, custom notices, and maybe a special branch
for senior executives.
None of those questions are unreasonable on their own.
But if you answer all of them in release one, you no longer have a first app.
You have a fragile negotiation between edge cases.
From a system perspective, that is not maturity.
It is early stage complexity debt.
Because the thing most people miss is that exceptions are real, but they are not equally important
at the beginning.
If you build around them too early, the main path gets buried under conditional logic,
extra fields, and unclear navigation.
The employee who just wants to request five days off now enters a process that feels
heavier than the old email.
So the new system loses before it even has a chance to teach a better habit.
There is another failure point that sits underneath all this.
And beginners usually do not see it until later.
Hidden licensing choices.
A team adds data verse, which may be the right architectural choice, but they do not stop
to ask what that means for licensing.
Then someone suggests a custom connector to some external HR endpoint because it sounds
small and elegant.
But a small integration choice can change the cost model fast because custom connectors and
premium capabilities are not just technical options.
They reshape the operating cost of the solution.
Now the app carries financial weight, the business never expected.
If that surprise lands after enthusiasm is already high, trust drops.
The same is true for environment shortcuts.
Building in the default environment feels fast.
It removes friction in the moment, but speed without boundaries usually creates cleanup
later.
What looked like convenience was actually governance debt waiting for a production conversation.
So first apps do not fail because power apps is weak.
They fail because teams confuse visible progress with structural clarity.
A good first app is not the one that answers every future question.
It is the one that proves the main path can become simpler, faster and more visible without
creating new fragility underneath.
That means we need to resist fake completeness.
We do not need every exception now.
We do not need the whole future architecture now.
We do need one clean definition of the problem, one clean entry point and one design choice
that improves business behavior immediately.
So before we choose canvas or model driven, we need to define the problem in operating terms
not screen terms.
Define the business problem in operating terms.
So let's define the problem the way the business actually feels it, not we need an app,
not we should modernize HR, not even we want to use power platform better.
Those are all directionally fine, but none of them are operationally useful because they
describe intention, not the work that is breaking.
At Contoso, the real problem is this.
Vacation requests enter the organization through too many paths, move with too little visibility
and depend too heavily on inbox behavior instead of a governed process.
That is the problem and once you say it that way, a lot of noise falls away.
Because now we are not trying to solve leave management in the abstract.
We are trying to solve request entry, decision clarity and status visibility.
That matters because if a problem statement is too broad, the app gets broad.
If the app gets broad, release one gets heavy and heavy first releases usually fail not
because the team lacks skill, but because they are trying to solve a category instead of
a bottleneck.
The current state inside Contoso is familiar and employee needs time off and starts with
whatever path feels fastest.
Sometimes that is email, sometimes it is teams, sometimes it is a local spreadsheet or
a manager saying yes, that should be fine with no formal record created at all.
Then HR gets involved later often after the fact trying to reconstruct what was requested,
what was approved and what policy should have applied in that country.
So the process exists but the operating model is fragmented.
And what does fragmentation create?
Delay, interpretation, inbox dependency.
A manager becomes a routing engine, HR becomes a reconciliation layer, the employee becomes
a follow-up mechanism.
That is not process maturity.
That is manual compensation.
Now, define the desired state just as clearly one request path.
One status model, one visible record of truth that does not mean every edge case is solved
on day one.
It means every normal request enters the business through a common door, carries a shared
set of status values and stays visible enough that nobody needs to rebuild the story from scattered
messages.
That is the operating shift.
And once you define it that way, the KPI becomes obvious, we want to reduce cycle time
from days to hours in some cases with later automation even minutes.
But for this episode, hours is already enough to prove the point.
Because if the request enters the business cleanly, the time lost to clarification, forwarding
and status chasing starts collapsing immediately.
There are supporting outcomes as well.
Approval SLA adherence improves because the request becomes visible and structured.
HR follow-up drops because the system now carries status instead of hiding it in mailboxes.
Absence planning gets cleaner because approved requests become easier to trust and report
on.
But those are supporting outcomes.
The main operating promise stays simple, shorten the time between employee intent and organizational
response.
Now you might be thinking, what about country rules, delegation and all the real world
variation, fair question?
Those are real constraints.
They are not reasons to delay problem definition.
In fact, they make good definition more important.
Because country policy complexity does not change the nature of the problem.
It changes the structure behind the process.
Delegation does not change the need for one request path.
It changes who can act when the manager is unavailable.
Those are design constraints inside the system.
They are not excuses to keep the front door vague.
This is where good app design starts getting more disciplined.
Not with pages, with three things, event decision status.
The event is the employee asking for time off.
The decision is whether that request fits policy and team reality.
The status is the visible state that tells everyone where the request now sits.
If you get those three right, the architecture starts to stabilize.
If you skip them, the app becomes decorative.
It may look useful, but underneath it is still asking people to carry too much meaning
in their heads.
Before we draw anything, we define the business problem in operating terms.
A request enters through inconsistent channels, moves through invisible decisions, and produces
unnecessary delay.
The solution, at least in release one, is not digital transformation.
It is a controlled entry point, a shared status model, and a faster path from request to response.
Now map that to how Contoso actually works today, and the architecture starts to reveal itself.
The process map behind a simple vacation request.
So now we move from problem definition into process shape, because once you know the bottleneck,
the next question is very practical.
What actually happens in order when a vacation request enters the business?
At first glance, this looks almost too simple to map, someone wants time off.
They ask, someone approves, done.
But simple processes often create the most hidden friction, because people assume shared
understanding when none really exists.
And when understanding stays implicit, the work gets pushed into memory, inboxes, and follow
up behavior.
So let's make the path visible.
The event is the employee submitting a request, that is the trigger, not a conversation,
not a draft in someone's notes, not an email chain with five replies and a sounds good to
me.
The actual process starts when the request becomes a record in the system.
Before that you only have intention, after that you have something the business can act
on.
That distinction matters more than it sounds, because if the event is vague, everything
downstream becomes unstable.
Managers respond inconsistently, HR reacts late.
These assume approval when none was formally recorded.
So the first architectural move is to define one clear event boundary.
Submission creates the request.
Then the process enters its first decision layer.
Does the request fit the basic policy structure?
Now for release one, we do not need to automate every policy nuance.
But we do need to know what the decision is trying to answer.
Other dates complete is the employee identified, is the manager relationship available, is
the country context known if policy differs by geography?
These are not advanced rules.
They are entry conditions.
And if the app captures them clearly, the next person in the chain does not need to reconstruct
basic context before making a decision.
Then comes the approval decision itself.
Can the manager approve this request or is delegation needed because that manager is absent?
This is where a lot of teams rush into automation too early.
They want escalation parts, substitutes, reminders, maybe even exception routing on day one.
But the cleaner way to think about it is this.
The request needs to move to the next accountable decision maker without the employee having to
guess who that is.
That is the structural job.
Whether that routing is fully automated now or just made ready in the data model is a maturity
decision, not a reason to muddy the first app.
Once a decision happens, the request changes state.
And state is where process design becomes visible.
For Contoso, we do not need 20 statuses that only creates interpretation that we need
a status model that reflects real movement, submitted, pending approval, approved, rejected,
cancelled.
That is enough for the first operating layer because each state tells the employee, the
manager and HR something materially useful.
It means the request exists, pending approval means ownership, sites with a decision maker,
approved and rejected, closed the decision.
Canceled Reflex change after submission without destroying the audit trail.
This is the thing most people miss.
Status is not decoration, it is shared operational language.
Without it, every participant starts asking side questions.
Did you see it?
Is it still waiting?
Was it declined?
Should I follow up?
Good status design removes those questions before they become behavior.
Now look at the data captured at each point.
At request time, we only need the data required for the next decision.
Start date.
And date.
Reason.
If the business wants it.
Employee identity.
Manager relationship.
Country context.
We're policy differs.
That is enough to create a valid request.
We do not need back office handling fields exposed to the employee.
We do not need every exception input on screen one.
We do not need the app to collect data just in case.
Because every extra field is the process admitting it does not trust its own downstream
structure.
So the cleaner pattern is this.
Capture what the next decision requires and let later automation or operations add
what only becomes relevant after that.
The employee should not carry policy interpretation that belongs in the system.
The manager should not carry routing logic that belongs in structure.
HR should not carry reconstruction work that belongs in status history.
Once the process map is clear at that level, the app decision gets easier because now we
are no longer debating interface style in the abstract.
We are deciding what kind of application best supports this exact operating behavior.
The architectural fork.
Canvas or model driven.
So now we reach the first real fork in the road.
And this is where a lot of teams make a decision far too casually.
They ask which app type is easier or which one looks better or which one they personally
prefer building in.
But that is not the real question because this is not a design-taste issue.
It is an operating model decision.
We are choosing how the business will interact with the structure we just defined and each
app type pushes behavior in a different direction.
Canvas is interaction first.
Model driven is structure first.
That is the cleanest way to hold it in your head.
A canvas app gives us tight control over the experience.
We decide what the employee sees first.
It stays hidden, what action feels obvious, how much context appears on a small mobile screen,
and how narrow we keep the path.
From a business perspective, Canvas is useful when the job is focused, repeated, and simple
enough that adoption rises when friction falls.
A model driven app starts somewhere else entirely.
It assumes the strength of the solution comes from the data model, the relationships, the
forms, the views, and the navigation that dataverse can generate around them.
It is less about shaping every pixel and more about giving people a governed workspace
where records, states, and relationships are visible in a consistent way.
From a business perspective, that matters when users are working across many records, many
filters, many statuses, and need operational oversight more than a tailored front door.
So neither is better in any universal sense.
Each one is optimized for a different job.
That point matters because beginners often choose canvas because it feels friendlier and
experience platform teams often lean toward model driven because it feels more governed.
Both instincts can be right, but both can also miss the structural question.
The decision should come from usage pattern, not familiarity.
Ask three things.
Who is using the app?
How often are they using it?
And how deep is the work they need to do once they are inside?
At Contoso, that changes the conversation immediately.
The employee requesting time off does not need a record management workspace.
They need a clear path, one action, minimal fields, fast confirmation, maybe mobile access
while away from a desk that leans toward canvas because the job is narrow and the value
comes from reducing hesitation at the moment of submission.
But now look at HR.
HR does not just need to submit a request.
HR needs to see patterns across requests filter by status review what is pending, understand
who approved what and eventually manage exceptions and operational follow-up.
That work starts leaning toward model driven because the value comes from visibility across
the data, not from a custom front end moment.
And then there is the manager role, which sits somewhere between the two.
A manager might only need a lightweight approval experience at first, which could live
comfortably in a canvas pattern or later in automation.
But if the manager role expands into broader oversight, team absence planning or delegated
approvals across multiple records, the logic starts shifting toward a more structured workspace.
This is why I would not frame the decision as application type alone.
I would frame it as behavioral fit.
Canvas fits best when you want to shape one path very intentionally.
Model driven fits best when you want dataverse relationships and process visibility to do more
of the work.
There is also a hidden architectural consequence here.
Canvas gives you more freedom, but freedom moves responsibility onto the maker.
You own the screen design, the interaction patterns, the consistency, the responsiveness,
and much more of the logic expression.
That can be exactly right for a strong front door, but it also means inconsistency shows
up faster if scope begins to sprawl.
Model driven gives you less expressive freedom, but in return it gives you more governed scale.
Navigation, views, forms and security alignment come more naturally because the application
grows out of the model itself.
That is powerful when the process is larger than one moment of entry, so if you remember
nothing else, remember this.
Canvas is usually the stronger choice when experience design drives adoption.
Model driven is usually the stronger choice when data relationships drive operational work.
Once you see that, the Contoso path starts to clarify.
They are not really choosing one app for one audience.
They are deciding which kind of experience belongs at the employee front door and which
kind of workspace may later belong behind it.
What canvas changes in the business?
So let's stay with that employee front door because this is where canvas starts to matter
in a very practical way.
A canvas app changes the business by reducing the amount of interpretation the employee has
to do before they act.
That sounds small, but it is not.
In most organizations, the hidden cost of internal processes sits in hesitation.
People are not always blocked by policy.
They are blocked by uncertainty.
Where do I go?
What do I fill in?
Who will see this?
And will this actually move if I submitted here?
A good canvas app removes those questions at the point where they normally slow everything
down.
Why canvas fits the employee side of Contoso so well?
The employee does not need to understand the full leave management architecture.
They do not need relational navigation.
They do not need views across all requests in the organization.
They need one clear action on a screen that feels obvious, fast and low effort.
Canvas lets us shape exactly that experience.
We can make the primary action visible immediately.
We can keep the field set narrow.
We can decide what stays hidden because it belongs to the system and not to the user.
And that changes behavior.
Because once requesting vacation becomes easier than writing the email, people stop improvising.
They stop creating side channels just to avoid friction.
They use the path that gives them the least resistance and now the least resistance is
finally the governed one.
That is the business shift.
Adoption no longer depends on training people into discipline.
It depends on giving them a better route.
This is also why canvas tends to work well in mobile first situations.
If someone is not sitting at a desk all day, the process cannot assume patience for clutter.
They cannot assume the employee will navigate a dense workspace just to ask for time
off next month.
The canvas app can be shaped around short interactions.
Open, enter dates, add reasons, submit, check status, done.
From a system perspective, that reduction in interaction cost improves data quality because
people are more likely to complete the request properly when the path feels contained.
But canvas does something else that leaders often underestimate.
It lowers the training burden.
That matters a lot in first releases.
Because every extra explanation you need before someone can complete a basic request is
evidence that the interface is carrying too much complexity.
A canvas app lets us design for familiarity instead.
One obvious button, plain labels, direct feedback after submission.
The employee should not need a walkthrough for something this routine.
If they do, the business has hidden complexity in the wrong place.
Now there is a trade-off and it is worth saying clearly.
Canvas gives us control but control creates responsibility.
The platform will not save us from inconsistent screens, unclear navigation, weak responsiveness
or bloated logic if we start stuffing too much into the app.
That freedom is useful when the scope stays narrow.
It becomes dangerous when the app starts absorbing every future idea.
Then the clean front door turns into a custom-built maze and maintenance gets heavier with every
addition.
So the strength of canvas at Contoso is not that it can do anything.
The strength is that we should ask it to do one thing very well.
Create the best possible request experience for employees.
That means the app should focus on speed, clarity and trust.
It should help the employee enter valid information without carrying policy complexity in their head.
It should confirm that the request exists.
And it should expose status in a way that stops people from falling back into inbox chasing.
That is what canvas changes in the business.
It does not just create a nicer form.
It changes the entry behavior of the organization.
Request start clean.
Status starts visible.
Adoption rises because the process feels simpler than the workaround.
But once you move from front door to operational workspace, a different logic starts to matter.
What model driven changes in the business?
So now let's move to the other side of the architecture because once the request is inside the system,
the business needs starts changing.
The employee needed a front door.
HR and operations need a workspace.
And this is where model driven starts to make much more sense.
A model driven app changes the business by making the data model itself operationally useful.
Instead of shaping every screen by hand, we let dataverse relationships, views, forms
and security do more of the heavy lifting.
That matters when the real job is no longer help one person submit one request but help
a role work across many requests, many states and many decision points without losing visibility.
That is a different class of work.
Think about HR at Contoso.
HR is not interacting with one record at a time in isolation.
HR needs to filter pending requests, review approvals by country, understand where delegation
applies and eventually spot where work is starting to stall.
That is not a single interaction moment.
That is an operational surface.
And model driven is strong precisely because it turns structured data into a governed environment
for that kind of oversight.
The benefit shows up fast, you get consistent navigation across related records, you get views
that let teams work by status, owner or geography.
You get forms generated from the model instead of custom building every path.
And you get security that sits naturally inside the dataverse structure instead of being
expressed mainly through interface design.
From a business perspective, that means scale arrives with less improvisation.
Now that does not mean model driven is automatically better for everyone.
It means it is better when the process extends beyond one form and into ongoing operational
work.
The people inside HR do not just need simplicity, they need control, visibility and repeatability.
They need to know that two people looking at the same request are seeing the same governed
record, not two slightly different interpretations of a custom app experience that consistency
matters more than people realize.
Because once the number of requests grows, trust starts depending on whether the process
behaves the same way for every record.
A manager may tolerate some interface variation in a lightweight employee app.
HR will not tolerate variation in the operational workspace for long.
They need stable views, predictable fields and filters that let them move from what happened
here to show me every request pending approval in Germany with a manager currently absent.
That is exactly where model driven begins to earn its place.
There is also a structural advantage that becomes more important as the process matures.
Model driven apps are naturally closer to governance, not in some abstract compliance
sense, but in the everyday reality of who can see what, who can update which records and
how process behavior stays aligned to dataverse roles and relationships.
That makes auditability feel less like an add-on and more like a byproduct of the architecture,
and that is a big deal for business operations.
Because once leave data becomes part of planning, staffing and accountability, visibility
is no longer a convenience.
It becomes a management requirement.
Leaders want to know if approvals are sitting too long.
HR wants to see whether one country is handling requests differently from another.
Modulation needs to be visible enough that absence does not create a silent bottleneck.
A model driven app supports that kind of operating reality much more naturally than a highly custom
front and trying to do everything itself.
There is a trade-off here too.
Model driven gives you strength through structure, but it gives you less freedom in how the experience
feels.
You are accepting a more standardized interaction pattern in exchange for a more governed
and scalable workspace.
For employees that can feel heavier than necessary, for operations that heaviness is often exactly
what keeps the process coherent.
So if Canvas helps the business by making entry easier, model driven helps the business by
making oversight stronger.
It turns the dataverse model into something people can actually work through at scale, and
it does that without asking the maker to custom build every piece of operational logic into
the interface.
So Contoso does not really have one user group.
It has one process with different depths of work, which means the app answer may not be
singular at all.
The Contoso decision, one problem, two experiences.
So this is the point where Contoso stops asking the wrong question.
The wrong question is which app type should we pick?
The better question is which experience belongs to which kind of work, because once we separate
the employee moment from the operational moment, the architecture stops feeling like
a platform debate and starts feeling like a business design choice.
At Contoso, the employee experience needs three things above all else, simplicity, speed,
and confidence.
The employee should be able to open the app, understand the action immediately, enter only
what the next decision requires and submit without wondering whether they use the right
process.
That is the front door problem.
And Canvas is usually the cleaner answer there because it lets us strip the experience
down to one focused task without dragging the user through the full shape of the underlying
model.
But that is only half of the picture.
Managers in HR are not just entering data.
They are working across requests.
They meet visibility, filtering, context, and the ability to operate on records with some
consistency.
HR especially needs a surface where status, employee relationships, country context, and
approval history can be reviewed without custom building every operational behavior into a separate
screen.
That is where model driven starts to make more sense.
Not because it is more advanced, but because it is better aligned to the depth of work those
roles are doing.
So, the Contoso answer is not one app trying to be everything for everyone.
It is one problem expressed through two different experiences.
That distinction matters because when teams force all roles into one interface, they usually
compromise both ends.
The employee app becomes too heavy because it carries operational complexity.
The HR workspace becomes too shallow because it was simplified for casual users.
The result is a single artifact that satisfies nobody particularly well, and the business
then concludes the process itself is awkward when the real issue was architectural blending.
From a system perspective, this is a separation of concerns problem.
The employee interaction is optimized for low friction.
The operational interaction is optimized for control and visibility.
Those are not the same design goals and they should not be forced into the same shape
too early.
So, for release one, I would recommend a clear front door decision.
Canvas for the employee request experience, that gives Contoso the fastest path to the
first value moment, which is not full leave management maturity.
It is much simpler than that.
An employee can submit a valid request through a governed path and then see that the request
exists, has a status and is now inside a process the organization can trust.
That is the breakthrough.
Once that happens, cycle time starts dropping because the request no longer enters through
scattered messages and private memory.
Now, does that mean model driven disappears from the story?
Not at all.
And model driven is more likely the operational layer that grows with maturity rather than
the first experience we push in front of every employee.
As Contoso expands the process as HR needs stronger oversight, as delegation reporting and broader
exception handling become more active concerns.
The structured workspace becomes more relevant.
And because the data model already lives in dataverse, that path stays open.
That is the quiet strength of this decision.
We are not choosing canvas instead of architecture.
We are choosing canvas as the right first expression of architecture for the employee side.
And that should calm a lot of unnecessary anxiety because some teams here hybrid and immediately
start over building.
They imagine they need two complete apps, full automation, all approval branches and future
reporting in version one.
They do not.
What they need is the first point of value clearly defined.
For Contoso, that point is request submission and status visibility.
Everything else can mature in sequence.
So the real decision is not canvas or model driven in isolation.
It is this.
Use canvas, where adoption depends on a better front door and leave room for model driven
where the business later needs a stronger operational workspace.
That is a very different mindset and it keeps version one honest.
Scope the first release like an architect.
So now we do the part that separates momentum from mess.
We cut scope.
Not because we lack ambition and not because the platform cannot do more, but because version
one has one job.
Prove the process can move faster through a controlled path without creating hidden cost
underneath.
If we forget that, the first release turns into a dumping ground for future ideas and
the architecture loses its center before the business trusts it.
At Contoso, release one should include only what the first value moment depends on.
The employee can create a vacation request.
The request is written to dataverse with the right core fields.
The request has a visible status.
The manager relationship is captured.
And the data model is ready for delegation.
Even if delegation handling is not fully automated yet, that last point matters.
Being ready for delegation is not the same as building the entire delegation engine
now.
In the other relationship, we can make the structure aware that a manager may have a delegate,
but we do not need to build every routing branch, notification path or fallback rule into
release one.
That would be future capability pretending to be current necessity.
The same logic applies to country policy.
Contoso has multiple countries.
Policies differ.
Everyone knows that.
But version one does not need to automate every country rule at the point of submission.
What it does need is structured country context in the data.
So later decisions reporting and automation have something reliable to work with.
What is how architects think?
We do not ignore complexity.
We place it where it belongs in sequence.
So what stays out of release one?
Advanced routing stays out.
Escalation stay out.
Reminder logic stays out.
Complex exception workflows stay out.
Heavy notifications stay out.
Full policy automation stays out.
And why is that?
Because those things do create value, but they create secondary value.
The primary value is clean entry, clean status and visible ownership.
If we win their first, the organization feels the change immediately.
If we chase completeness first, the team spends energy on branches before the main path
has even earned trust.
This is the part many teams resist.
Because scoping small can feel like underbuilding.
It can feel as if we are leaving obvious opportunities on the table.
But that feeling usually comes from confusing architectural readiness with feature volume.
A good first release is not the one with the most moving parts.
It is the one that creates the clearest shift in operating behavior with the fewest assumptions.
That also protects us from licensing surprises.
The more integrations, connectors and orchestration ideas we drag into version one, the more
likely we turn the straightforward app into a more expensive service pattern than the business
expected.
The first release should buy options, not consume them recklessly.
Keep the architecture clean now.
And you preserve room to automate later, without discovering that a small design flourish
quietly change the cost model.
It also protects governance.
A tightly scoped first release is easier to place in the right environment, easier to test,
easier to secure and easier to explain.
The people inside the system know what it does.
Support knows what to expect.
You can see the point of the release, without needing a maturity map and a three layer process
diagram just to understand what shipped.
So if I were scoping Contoso's first release as an architect, I would state it plainly.
One employee entry path, one request record, one shared status model, one visible owner
for the next decision, delegation readiness in the data, country context, captured structurally.
Everything else waits until the first behavior change is real because maturity does not come
from stuffing the future into version one.
It comes from sequence.
And once scope is under control, we can finally design the employee experience from first principles.
Design the employee experience from first principles.
So now we design the part people actually feel, not the table, not the relationship map,
not the future approval engine, the employee experience.
And the cleanest place to start is not with controls.
It is with the human moment that triggers the process.
At Contoso, that moment is very ordinary.
Someone needs time off, maybe for family, travel, recovery or just a break and they want
two things immediately.
Clarity and confidence.
Clarity about what to do.
Confidence that the request will not vanish into informal manager memory.
If we keep that moment in view, the app becomes much easier to design because now we are not
asking what can the platform show?
We are asking, what does this person need to do with the least friction and the lowest
chance of error?
That question strips away a lot of noise.
It tells us the screen should not feel like HR software.
It should feel like a simple act of intent entering a reliable system.
That means the field set stays minimal, start date, end date.
And the reason if Contoso wants a short explanation and country context only where it is truly
needed or already known.
That is enough for the next decision.
Everything else needs to justify its existence.
If a field does not help validate the request now or move it to the next accountable person,
it probably does not belong in front of the employee.
This is where many apps start carrying back office uncertainty on the user's back.
Teams add extra inputs because someone downstream might want them later, but every extra field
is usually structural compensation for a week process.
If the system is well-shaped, the employee should not have to fill gaps that the architecture
should already know.
The manager relationship should come from the data model.
Basic employee identity should already be known.
Country should be inferred where possible.
Status should be created by the process, not typed by the request that is how you reduce
cognitive load.
And cognitive load matters more than people think because internal business apps fail
quietly.
The employee may not complain.
They just delay using it, ask a manager in chat instead or submit incomplete information
because the interface asks them to think harder than the old workaround.
The good design is not about visual polish, it is about lowering the cost of doing the
right thing.
There is another part that belongs in the first principles view and that is immediate feedback.
The moment a request is submitted, the employee should know three things.
The request was captured, its current status, and who owns the next decision that tiny loop
changes trust fast because once people can see that the process has accepted their intent
and attached visible ownership to it, they stop treating the request like a social favor
and start treating it like a real operating flow.
This is where the app begins to shift culture without announcing that it is doing so.
Now what should stay out of the employee experience?
Anything that belongs to back office handling?
Approval routing details stays out, operational comments stay out, exception management stays
out.
Administrative override logic stays out.
Not because those things are unimportant, but because they belong to other roles and
later moments in the process.
If we expose them too early, the employee interface starts leaking internal complexity.
Then the front door stops being a front door and starts becoming a badly compressed view
of the entire system and that is exactly what we are trying to avoid.
So the design principle is simple.
Make the next action obvious, keep the mental load low and let the structure carry what
the user should not have to carry.
In practice that means short paths, plain language, few choices and visible confirmation.
The app should feel almost boring and boring is good here.
Boring means predictable, predictable means trusted, trusted means used.
And once that happens, the request path stops depending on memory, email threads and good
intentions because the system finally gives the employee a front door that feels easier
than the workaround.
Walk through the first screen in plain language.
So because this is audio, let me describe the first screen the way a user would actually
experience it, not the way makers usually talk about it.
An employee opens the app and the first thing they see is one obvious action, request vacation,
not five tiles, not a busy dashboard pretending every option matters equally.
Just a clean front door with a clear primary action because the app should answer the user's
first silent question immediately.
Am I in the right place to do this?
That matters more than people think.
If the first screen asks the employee to interpret where to begin, the process has already
reintroduced friction.
We are trying to reduce decision cost, not relocated, so the page should feel calm.
The title tells them what the app is for.
The main button or form area tells them what to do next.
And around that, only enough supporting context appears to build confidence, not clutter.
Once they choose to request vacation, the interactions stay short.
They enter a start date, they enter an end date, they add a reason if contoso wants one.
And they can see without hunting, which manage a relationship the system is using for the
request.
That last point is useful because it removes a common hesitation.
People often want quiet confirmation that the request is going to the right person.
They should not have to remember who sits where in the approval chain.
The app should already know enough to make that visible.
Now notice what is not happening.
The employee is not picking workflow branches.
They are not deciding policy logic.
They are not filling in operational metadata for HR.
They are not choosing from fields that only matter later.
The screen is intentionally narrow because every unnecessary choice introduces the chance
of pause, error or abandonment.
Then for a first app, that is the risk we are actively designing against.
Then comes the submit moment and this is where the experience has to feel concrete.
When the employee taps submit, the system writes the request to dataverse immediately.
No attachment chain starts, no one needs to forward an email.
No hidden mailbox rule catches the message and dumps it somewhere opaque.
A structured record is created in the system of record.
The moment intent becomes formal.
That is a very different operating event from sending an email.
With email, the employee hopes the process begins.
With the app, the process begins.
And because the process begins at record creation, the next screen or confirmation state
should show that back to the user in plain language.
Something simple.
Request submitted.
Status.
Submitted or pending approval.
Depending on how contoso labels the first visible state.
Next decision owner.
Manager name.
If that is appropriate to expose.
The point is not decorative feedback.
The point is to show that the request now exists inside a governed flow.
That feedback loop changes trust fast.
The employee no longer wonders whether the request got lost.
They no longer need to screenshot a team's message.
They no longer need a second message that says, "Just checking if you saw my leave request."
The app has reduced ambiguity at the exact point where ambiguity used to create extra work.
And when they return to the home view, they should be able to see recent requests with
their current statuses.
Not a giant case management console.
It's enough history to answer the natural follow-up question.
What happened to my last request?
And where does this one stand now?
That simple visibility starts retraining behavior.
Because the employee learns that status lives in the system, not in social memory.
This is why I keep saying simple interface design is really process design made visible.
What looks like a basic first screen is actually carrying several architectural decisions at once.
One governed entry point.
One immediate right to that averse.
One visible status loop.
One reduction in inbox dependency.
From a business perspective, that is already a meaningful shift because the organization has
moved from informal request handling to structured request intake without asking the employee
to absorb the full complexity underneath.
That is the mark of a good first screen.
It feels light to the user because the architecture is carrying the weight for them.
What dataverse is doing underneath the app.
Now let's step below the screen because once the employee taps submit, the visible experience
ends for them, but the structural work is only just beginning.
And this is where dataverse matters.
Underneath that simple request form, dataverse is creating a standardized record, not just
storing a few loose values in a convenient place.
That distinction matters because storage alone does not create order.
Structure creates order, the app collects the request, but dataverse defines what that
request actually is inside the business.
So when the employee submits vacation dates, reason, and manager context, dataverse writes
that into a request table with controlled fields and controlled states.
Start date means the same thing every time.
And date means the same thing every time.
Status is not free text.
It is a known value inside a shared model.
That is what protects the process from slowly dissolving back into interpretation.
And why is that so important?
Because if the app alone carries the logic, the solution becomes fragile fast.
An ice-screen can guide behavior, but the moment someone builds a second app, adds reporting
introduces automation or opens the data to HR operations.
In consistency, start spreading unless the data layer is already enforcing the same structure
underneath.
So the app is not the source of truth.
The app is the front door into the source of truth.
That is a cleaner division of responsibility.
The Canvas app handles interaction.
Dataverse handles structure.
The app helps the employee do the right thing with the least friction.
Dataverse makes sure the thing they entered becomes a reliable business record.
The rest of the organization can trust.
And once you hold that split clearly, the architecture stops feeling mysterious.
Now inside Contoso, this request record does not sit alone.
It connects to other records that give it meaning.
The vacation request links back to the employee.
It links to the manager relationship.
It can link to country context where policy differs.
And it can be shaped so delegation becomes possible later without rebuilding the model
from scratch.
That is where dataverse starts earning its place because relationships are not just
nice technical features.
They are how the business stops asking the same questions over and over again.
Who requested this?
Who is supposed to approve it?
Which country rules may apply?
What state is it in right now?
A weak data layer forces people to answer those questions repeatedly through memory and
messages.
Strong data layer stores the answers in a form the whole process can use.
This also protects future reporting.
If every request enters with standardized fields and status values, leadership can later
look across the process without cleaning up a hundred local interpretations first.
HR can group by country.
Teams can review pending approvals.
Operations can start seeing whether delays are random or structural.
None of that works well if the first app writes messy records into the back end.
So even a small first build needs discipline in the model because later visibility depends
on decisions made now.
There is another benefit people often miss.
Dataverse lets the model carry readiness for future automation without forcing automation
into release one.
That is exactly the position Contoso needs.
We are not yet building the full approval engine in this episode.
But if the request record already contains the right relationships, the right status values
and the right ownership signals, then power automate can later move that record through
the business without us redesigning the foundations.
That is what good architecture feels like, not overbuilt.
Just ready.
So when I say the app writes to dataverse immediately, I am really saying something bigger.
The request stops being a message and becomes a governed object in the business.
That object can be queried.
It can be secured.
It can be reported on.
It can be rooted later.
And it can stay visible long after the original submission moment is gone.
That is the structural handoff.
The employee sees a simple form.
The organization receives a standardized record with relationships, status and future process
value already intact.
Once you understand that split, the build feels less like magic and more like architecture
because the screen is only one layer.
The real strength sits underneath where dataverse keeps the process coherent even as the solution
grows.
Why this small build has outsized business impact.
So now we can answer the question that usually sits in the room once a first app is described
this simply.
Can something this small really matter that much?
Yes, because business drag often does not come from missing giant systems.
It comes from weak entry points.
And when you repair the entry point, you change everything that used to pile up behind
it.
That is exactly what happens at Contoso.
Cycle time drops first.
Not because the approval logic suddenly became brilliant and not because low code performed
some miracle, but because the request no longer begins life as an unstructured message.
That one change removes a surprising amount of delay.
Nobody has to decode an email.
Nobody has to ask for missing dates that should have been captured up front.
Nobody has to forward the request manually just to get it into the right line of sight.
A structured request starts cleaner and clean starts move faster.
Managers feel this quickly.
Before the app, a manager had to function like a personal routing layer.
Most arrived in different channels at different times with different levels of detail.
Some lived in outlook, some sat in teams, some existed only in a conversation that everyone
assumed would be remembered later.
That creates overhead even before a decision gets made.
With the app, the manager no longer spends energy reconstructing what the employee meant.
The request already exists in a known state with enough context to act on it.
HR feels a different kind of gain.
HR does less follow up because every request now enters the same path.
That does not eliminate HR work.
It removes reconciliation work.
And those are not the same thing.
HR work adds value.
Reconciliation work just patches inconsistency.
When every vacation request enters through one governed front door, HR stops burning time
on preventable ambiguity and starts working with records that carry their own structure.
Employees feel something even more important.
They begin to trust the process.
That trust matters because in weak internal processes, people often create their own safety
nets.
They send a request, then they message the manager, then they save a copy.
Then they ask HR a few days later if anything was recorded.
That behavior looks personal, but it is a system outcome.
People build backup behavior when the formal path does not feel reliable.
Once the app gives them visible status and visible ownership, a lot of that compensating
behavior starts to disappear.
And that is why one form can change throughput.
It is not just collecting data.
It is removing ambiguity at the point where ambiguity used to multiply.
A request is now a record.
A record has status.
Status has meaning.
Meaning reduces chasing.
Chasing was where a lot of the wasted time lived.
This is also where structural resilience starts becoming visible.
Before the app, the process depended on memory, responsiveness and goodwill across scattered
tools.
That is fragile.
It creates hidden single points of failure everywhere.
One busy manager delays the process.
One missed email breaks continuity.
One absent HR colleague turns the whole thing into detective work.
After the app, the process does not become perfect, but it becomes more resilient because
the request exists independently of any one person's inbox habits.
That distinction is big.
Convenience helps individuals.
Visual resilience helps the business.
And this first build does the second one.
It creates a more reliable operating path for a common internal request.
And because vacation requests happen repeatedly, every small reduction in friction compounds
over time.
What looks like a modest app is actually changing, request quality, visibility, accountability
and trust all at once.
So when someone asks whether this is too small to matter, I would turn the question around.
If a process happens every week across countries, across managers, across HR, and it still
begins in scattered messages.
How expensive do you think that fragmentation already is?
The value did not come from low code.
It came from design.
And this is usually the moment where the platform gets too much credit.
People see the first app working.
They see the request captured.
They see status becoming visible.
And they conclude that low code itself created the value.
But that is not quite right because tools do not create operating clarity on their own.
They accelerate whatever design logic we bring into them.
If the thinking is clean, low code helps us express it faster.
If the thinking is weak, low code helps us spread that weakness faster too.
That distinction matters, especially for first time teams because power apps can make it
feel as if speed equals correctness.
You drag controls onto a screen, connect the table.
And in a very short time, you have something that looks like software.
That is powerful.
But appearance is not architecture.
A working screen is not proof of a good operating model.
It is only proof that the platform can express what we asked it to express.
So if Contoso gets cycle time reduction from this first app, that value did not come from
the fact that the app was built with low code.
It came from a set of design decisions.
One clear event boundary, one governed record, one shared status model, one cleaner entry
path, one separation between user experience and data structure.
That is where the business outcome came from.
The platform helped us move faster, yes.
It reduced the build friction.
It shortened the time between idea and usable interface.
But if we had taken the old email mess and simply wrapped it in a nice looking screen,
the result would still be messy.
It would just be messy in a more modern wrapper.
That happens all the time.
Sometimes digitize a bad process and then wonder why the business still feels slow because
the process did not change.
Only the container changed.
This is the thing most people miss when they first get excited about power platform.
They think low code removes the need for design discipline.
Actually, it increases the need for it because the speed of building means poor assumptions
can move into production before anyone has really challenged them.
The system is doing exactly what we told it to do.
It is just not doing what the business actually needs.
So when I say the value came from design, I mean design in the operational sense, what
event starts the process?
What data belongs at that moment?
What decision comes next?
What status language reduces ambiguity?
What belongs in the interface?
And what belongs in the model?
Those are design questions.
And once you answer them well, the platform becomes a force multiplier.
That is where low code becomes genuinely useful for leaders.
Not because it replaces architecture, but because it shortens the distance between architectural
clarity and business execution.
If we know what kind of process behavior we want, power apps and data verse, let us implement
that intent much faster than a traditional development path would for something of this
size.
But speed only helps when direction is right.
Otherwise you get a faster route to confusion.
A bad process in a polished screen stays a bad process.
A good structure in a clear interface changes behavior quickly because the user no longer
has to compensate for weak design with extra memory, extra messages and extra follow-up
work.
That is the actual leverage here, not low code as magic, low code as compression.
It compresses the distance between thought and system behavior.
So for Contoso, the lesson should be very clear.
Do not walk away thinking about power apps solved our vacation request problem.
The better conclusion is, once we design the process boundary properly, power apps gave
us a fast way to express that design in the business.
That is a much more useful lesson because it scales.
It means the next internal app should not begin with features.
It should begin with process shape.
It means leaders should not ask, what can the platform do?
Before asking, what operating behavior are we trying to create?
And it means makers should stop treating the tool like the source of value because tools
expose design quality more than they replace it.
Which brings me to one mistake almost every first time team makes.
The first trap, building in the default environment.
So now we get into the first trap and this one catches teams precisely because it feels
convenient.
The default environment is sitting there already.
It is available.
It feels close at hand.
You can open power apps, start building, connect the table, share something quickly and
for a small proof of concept that convenience can feel harmless.
But the moment you move from experiment to operating solution, that convenience starts
turning into structural drag.
And why is that?
Because the default environment is not a neutral place.
It is a shared space with broad ambient access patterns, mixed ownership and weaker boundaries
than you want for something that is supposed to become a real business process.
From a system perspective that is not just untidy, it is fragile.
You are building an operational front door on top of a space that was never meant to carry
clear production discipline.
At Contoso, that matters fast.
The vacation request app may look small but it is not low impact.
It affects employee records, manager accountability, process trust and eventually reporting.
So if we place that in the default environment simply because it is easy, we are teaching
the organization a bad lesson early.
We are saying the path from idea to production is just build where you happen to be standing.
That is how sprawl starts.
And once sprawl starts, several things happen at once.
Ownership gets blurry, support gets blurry, change control gets blurry, and security assumptions
start depending on who happened to create what rather than on intentional operating boundaries.
What is the real issue?
The default environment makes accidental architecture very easy.
Now I want to keep this proportional.
This episode is not a full governance deep dive and I do not want beginners thinking they
need a center of excellence before they can build one useful app.
You do not.
But you do need one simple habit very early, separate experimentation from operation.
If you are testing an idea fine, test quickly.
If you are creating something the business will rely on, move into an intentional environment
strategy as early as possible.
That shift changes behavior.
A dedicated environment says this solution has a life cycle.
It can be developed, tested, secured, and later supported with more discipline.
It creates a cleaner boundary for who builds, who accesses, and how changes move over time.
That is not bureaucracy.
That is structural resilience.
There is also a practical point here.
Governance and power platform has been moving toward more visibility, more managed environments,
and better tooling around app inventory and risk.
Organizations without governance see much higher rates of app sprawl and security issues
according to the research.
So even if this first app is modest, you want to build in a way that can mature cleanly
later.
Otherwise the first success becomes the first hidden liability.
The default environment is especially risky because it normalizes shortcuts.
Shortcuts around ownership, shortcuts around deployment, shortcuts around support expectations.
And once users begin depending on the app, every shortcut becomes more expensive to unwind.
That is why I would frame the default environment as a proof of concept zone, not an operating
home.
For early exploration, yes, a safe long term place for a governed leave request process.
No, the process may be simple, but the people inside it still deserve stable boundaries.
So if you are listening to this while planning your own first power app, take one practical
step.
Before you publish broadly, ask yourself, is this app still an experiment, or is it now
part of how work gets done?
If it is how work gets done, treat the environment choice like an architectural choice, because
it is one.
The wrong environment does not usually fail loudly on day one.
It quietly accumulates risk until support, visibility and control all start costing more than
the original speed save.
And that is the irony.
Teams choose the default environment to move faster.
But for operating solutions, it often slows maturity later because the system is doing
exactly what that convenience allowed.
Growing without boundaries.
The second trap accidental premium cost.
And the second trap sits right next to the first one because even when teams avoid environment
chaos, they can still create cost chaos without noticing.
This usually happens in a very ordinary way.
Someone says it would be nice if the app also connected to this other system.
And on the surface, that sounds harmless.
One more connector, one more convenience.
One little enhancement to make the process feel more complete.
But architecture has a habit of changing the business in places people are not looking
and licensing is one of those places.
So let me make this very plain.
The moment you build your first app, you are not only choosing an interface.
You are also choosing a cost shape.
That matters a lot in 2026 because power apps licensing has become less forgiving for
casual architectural drift.
Basic writes inside Microsoft 365 cover standard scenarios.
But the second you bring in data verse, premium connectors or custom connectors, the conversation
changes.
And not a little structurally.
For Contoso, we are already making one intentional decision that affects licensing.
We are using data verse.
That is fine.
It is justified because the process needs structured relationships, governed data and a
clean path to future automation.
So this is not a warning against data verse.
It is a warning against thoughtless expansion once you are already there.
Because if someone then says, let's also connect to a niche HR endpoint or let's pull manager
logic from a custom API or let's add one custom connector to enrich the request that small
design choice can shift the operating cost of the solution faster than the team expected.
And why is that?
Because custom connectors are premium, premium connectors change licensing requirements.
And one app can quietly drag a whole audience into a different cost model if the architecture
is not kept under control.
This is the part many first time teams miss.
They think licensing changes when the app gets bigger.
Often it changes when the connector list changes.
That is a very different risk pattern.
A simple vacation request app can look operationally modest while becoming commercially heavier
underneath.
Not because the business problem got more complex, but because the solution design wandered
into unnecessary integration, the screen still looks small.
The license footprint does not.
So for a first release, the discipline is simple, avoid external complexity unless it
is clearly required for the first value moment.
Do we need a custom connector to prove that employees can submit govern vacation requests
into dataverse with visible status?
No, do we need broad cross-system orchestration before the business has even validated the
new front door?
No.
Do we need to turn a clean first app into an integration project just because the platform
makes that technically possible?
Definitely not.
This is where architecture protects business reality.
A narrow design does not only reduce build effort.
It preserves optionality if Contoso keeps the first app focused on dataverse, the employee
experience and a clear status model, then later integration decisions stay available.
We can still add flows, we can still enrich routing, we can still connect other systems
when the business case is real enough to justify the cost.
But we do that from a position of intent, not because version one quietly accumulated expense
through enthusiasm.
And there is another reason to stay disciplined here.
Cost surprises, damage, trust.
If leadership hears low code and expects a lightweight first solution, then discovers that one small
design decision changed licensing expectations across a wider user group.
The platform gets blamed for something that was really an architecture choice.
That is avoidable.
We just need to say early what the solution is and what it is not.
So the rule I would apply in Contoso is very straightforward.
Use the minimum architecture that supports the first business outcome.
If standard capabilities and dataverse are enough to create the govern request path,
stop there for now.
We're not add premium complexity just to make the first release feel more impressive.
Impressive first releases often age badly clear first releases create options.
So yes, licensing matters more than many teams expect, but the answer is not fear.
It is intentional design.
Keep the first app clean, keep the connector story simple and let the business earn the right
to expand the cost model later.
Once the value is visible and the next architectural move is actually justified.
Handling real world complexity without bloating release one.
So now we get to the part that usually derails good first apps.
Real world complexity is real.
It is not imaginary.
It is not a lazy objection from the business.
Contoso really does have multiple countries policies really do differ.
Managers really are absent sometimes.
Delegation really does matter.
And because all of that is true, teams often jump to the wrong conclusion, which is if the
complexity is real, version one must contain all of it.
It should not.
What version one needs is not full behavioral coverage.
It needs structural readiness.
That is a very different standard.
And once you see the difference, the architecture becomes calmer.
We are not pretending complexity does not exist.
We are deciding where that complexity should live first so the business can grow into it
without dragging every future rule into the first employee experience.
Take multi-country policy as the first example.
If employees in Germany, the UK and the US follow different vacation rules, that matters.
But the first release does not need to expose every policy branch directly in the app.
What it does need is a clean way to associate a request with the right country context so
the system knows which policy frame may apply later.
That means country belongs in the data model first.
It becomes a structured attribute, not a guessing exercise and not a hidden assumption in
someone's head.
That one move does a lot of work.
It preserves reporting value.
It preserves future automation value.
And it keeps the app from turning into a policy encyclopedia on day one.
That is the pattern I want you to remember.
When complexity is real, put it into structure before you put it into behavior.
Now take delegation.
Manager absence is one of those small operational truths that can quietly break a process.
If the approval path depends on one person and that person is on leave, traveling or simply
unavailable, the process stalls.
That is a single point of failure.
So delegation matters early.
But again, readiness does not mean full automation.
In release one, Contoso can model the idea that a manager may have a delegate.
That relationship can exist in dataverse.
It can be visible to the architecture.
And it can be ready for later flow logic without forcing the employee app to care about
it yet.
That is a good example of future ready design.
We acknowledge the operating rule.
We capture it structurally.
We delay the heavier orchestration until the first path is proven.
Because if we try to build every delegation branch now, we immediately pull in more status
logic, more rooting logic, more exception logic and probably more notifications too.
The build expands fast.
Testing expands with it.
Support complexity expands with it.
And suddenly the first release is no longer about making request intake trustworthy.
It is about simulating every edge case the organization has ever experienced.
That is not maturity.
That is sequence collapse.
And this is where good architecture earns trust because it tells the business, yes, your
complexity is valid.
And no, we do not need to operationalize all of it at once to move forward responsibly.
There is a big difference between overbuilt and future ready.
Overbuilt means the solution carries behavior the business has not yet validated.
Future ready means the model carries enough structure that validated behavior can be added
later without tearing up the foundation.
Contoso needs the second one.
So if I were pressure testing release one, I would ask very simple questions.
Can the apps stay easy for the employee?
Can the request enter a dataverse with the right country context?
Can manage a relationship to be trusted?
Can delegation exist in the model?
Even if rooting weights?
Can we add automation later without redesigning the request object?
If the answer is yes, we are in a good place.
Because maturity does not come from stuffing everything into version one.
It comes from designing a path where each next layer has somewhere clean to land.
And once you understand that complexity stops feeling like a reason to stall.
It becomes a reason to sequence carefully.
Why this app should feel boring to the user?
So now we get to a word most teams hate when they are building internal apps.
Boring.
They want the app to feel modern, smart, polished, maybe even a little impressive.
But they want the first reaction to be wow, this looks great.
But for a process like vacation requests, that instinct usually points in the wrong direction
because the employee is not opening the app for an experience.
They are opening it to complete a simple task with as little uncertainty as possible.
That changes the design standard completely.
For the employee, boring is good.
Boring means the app is predictable.
Boring means nothing on the screen asks for interpretation.
Boring means the same action produces the same result every time.
And in business processes, predictability is a form of trust.
If an employee can ask for time off without training, without second guessing, the wording,
and without wondering whether they chose the wrong path, the app is doing its job.
It is not supposed to entertain.
It is supposed to remove ambiguity.
That is a very different goal from a showcase app.
And if we forget that, we start adding visual cleverness where operational clarity should
have been.
This is where many teams confuse sophistication with quality.
When they add extra navigation, they add more options than the user really needs.
They decorate the screen with status widgets, tiles, menus, and supporting information that
feels helpful in theory but creates noise in practice.
Then the employee opens the app and has to think before acting.
The process now looks more advanced, but structurally it has become slower.
And why is that?
Because every extra design choice increases the mental effort required to do something
that should have stayed obvious.
The business consequence is subtle but real.
Users hesitate.
They postpone.
They ask someone in chat just to confirm what the interface should already have made clear.
Support requests rise, work around survive.
None of that happens because people are resistant.
It is a system outcome.
The interface created interpretation cost where the process needed certainty.
So yes, this app should feel boring.
The employee should open it and immediately know where to begin.
They should see familiar language.
They should complete the request in a short path.
They should get a clear confirmation.
Then they should leave.
That is good design for this use case because the app is not trying to expand their engagement.
It is trying to minimize the cost of compliance with the process.
When people can do the right thing quickly, adoption goes up without campaigns because the
govern path becomes easier than the work around.
There is also a scale reason for this.
Contoso is not designing for one enthusiastic early adopter.
It is designing for many employees across countries with different habits, devices and tolerance
for internal tooling.
That means simplicity is not a lack of depth.
It is what allows the process to travel well across the organization.
The more ordinary the user experience feels, the less support the business needs to
carry later.
And support burden matters.
A flashy app that needs explanation is expensive in a way teams rarely model upfront.
A boring app that people understand instantly is cheaper to run easier to trust and less likely
to fragment into local workarounds.
That is what scale looks like in internal systems, not visual originality, operational consistency.
So if someone at Contoso says the first release feels too simple, I would take that as a positive
sign.
Simple means the employee does not have to understand the architecture.
Simple means the complexity state where it belongs.
Simple means the front door is doing its job.
And for a first app that is exactly what we want.
Because when the user experience becomes boring in the right way, the business gets something
much more valuable behind it.
Repeatable behavior.
The transformation moment inside the business.
And this is the point where the conversation inside Contoso starts to change.
Up to now, power platform may have lived in people's heads as a category, a promise, maybe
even a debate.
Useful for prototypes.
Interesting for makers.
Possibly relevant later, but once the first app is live and people can feel the process
moving differently, the discussion stops being theoretical.
It becomes operational.
That shift matters.
Because organizations rarely change their minds when you explain the platform better.
They change their minds when the business starts behaving differently in front of them.
One employee submits a request in seconds, a manager sees a real record instead of a vague
email, HR stops chasing context.
And suddenly the platform is no longer something we could use.
It is something that just changed a piece of business reality.
For leadership, this is often the first real signal, not that low code exists, not
that data versus structured.
Not that Canvas apps are flexible, those things matter, but they are still platform language.
What leadership notices is cycle time moving.
A request that used to sit in inbox drift now enters a governed path immediately.
Ownership becomes visible.
Delay becomes easier to see.
That turns process speed into something concrete.
And once leaders see process speed improve without a full custom development project, they
start understanding the platform in a different category.
Not as a side tool.
As an operating lever, I'd feel the different transformation.
For first, wind like this, internal requests often arrive as backlog pressure.
Every small process problem sounds like a software project.
Every improvement request competes with larger priorities.
That creates tension because the business experiences friction everywhere, but central
delivery capacity cannot absorb every operational fix.
A working first app changes that story a little.
It shows there is a controlled path between this process is inefficient and we need a major
build.
That does not remove the need for architecture.
It raises the importance of it because now IT can see a model where smaller process interventions
become possible without surrendering standards completely.
The platform becomes a way to absorb demand more intelligently provided the structure underneath
stays disciplined.
That is why early winds matter so much.
They do not just solve one use case.
They change what the organization believes is possible.
The business teams feel something else again.
They stop assuming that process pain is just normal.
That is a bigger shift than it sounds.
In many organizations people adapt to drag so completely that they stop questioning it.
Email chains, manual follow ups, invisible status and local workarounds become part of the
culture.
Then a small app comes in and removes one layer of that friction and suddenly people
can see that the old pain was never inevitable.
It was just embedded in the way the process had been shaped.
That is a powerful moment because it moves the conversation from complaint to redesign.
Instead of saying this process is annoying people start asking where else are we doing
this the hard way.
And that question is where maturity begins, not platform maturity, organizational maturity.
Because once one request path becomes cleaner other weak entry points become easier to recognize.
Expense approvals, equipment requests, internal service asks, HR changes.
The first app creates a pattern people can now see, event record status owner visibility.
That pattern becomes portable.
But there is a tension here too.
A first success creates appetite and appetite can be dangerous if the organization learns
the wrong lesson.
If contoso concludes that power platform means we can build everything quickly the next
wave will create chaos.
If contoso concludes that structured design plus the platform can improve specific operating
paths quickly then the first app has taught the right lesson.
That distinction is everything because the real transformation is not excitement.
It is seriousness.
The business starts taking process design more seriously because it has seen one example
of design turning into throughput.
IT starts taking low code more seriously because it has seen a controlled use case create
value without bypassing architecture.
Leadership starts taking internal process speed more seriously because it can now connect
software shape to business performance that is the transformation moment, not applause
for the app.
A new understanding that process friction is designable that cycle time can move without
giant programs and that technology does not only automate work.
It changes the conditions under which work happens.
Why the app only solves half the problem?
So this is where we need to stay honest.
The app solves a real problem but it does not solve the whole problem.
It fixes entry.
It does not yet fix movement and that difference matters more than people expect because once
a request enters data verse cleanly the organization often feels a sense of relief and starts
assuming the process is now handled.
But a record sitting neatly in a table is not the same thing as work progressing through
the business.
A good front door improves intake.
It does not guarantee flow at contoso the employee can now submit vacation properly.
That is a meaningful shift the request exists the data is structured ownership is visible
at the starting point status begins from a govern baseline all of that is good.
But after submission something still has to happen someone has to be prompted someone
has to act if they do not the request can still stall only now it stalls more neatly
than before.
That is why I would separate two kinds of capability very clearly the app handles interface.
The next layer handles orchestration and if we blur those two we start expecting the
wrong thing from the first build.
An interface is about capturing intent well it gives the employee a clean way to enter
the system it lowers friction reduces ambiguity and makes the opening event reliable but
orchestration is different orchestration is what moves a request from one accountable
state to another.
It is what turns a clean record into a progressing process that includes things like rooting who
should be asked next it includes reminders what happens if the manager does not respond
it includes escalation what happens if the approval window starts slipping and it includes
hand off logic what happens if the assigned approver is absent and delegation needs to take
effect those are not screen questions those are flow questions and once you see that the
architecture becomes easier to reason about the canvas app was the right move for the front
door because the front door needed simplicity but the moment a request exists a different
kind of system behavior has to take over not better visuals better movement this clicked
for me years ago when I saw teams celebrate a successful form launch then wonder why cycle
time only improved part of the way the answer was always the same submission got better
throughput did not fully change because the request still depended on manual follow up after
entry the system had learned how to receive intent but not yet how to carry intent through
the rest of the path that is exactly the point contoso is reaching now the employee side
is cleaner the operating path behind it is still partially manual so a manager may still
need prompting HR may still need visibility on delay delegation may still depend on human
intervention the request may still sit too long in one state if no automation keeps it moving
that does not mean the app failed it means the app solved the first half well enough that
the second half is now visible and from a business perspective that is progress because
hidden process weakness is much harder to improve than visible process weakness before the
app intake and flow were both messy at the same time so everything blurred together now
the entry point is cleaner which means the remaining drag stands out we can see where
movement still breaks down that is a good outcome that gives us a sharper problem statement
for what comes next not build more app but design the flow layer that carries this governed
request through approvals reminders and state change without depending on inbox habits which
brings me to the next architectural move once the request exists in data verse as a proper
business object automation becomes the force multiplier not because automation is trendy
and not because every process needs a giant workflow but because a clean record without
movement still leaves throughput exposed the form collected intent the next layer needs
to create motion so if this episode was about giving the business a proper front door the
next one has to deal with the corridor behind it because that is where requests either
move with discipline or quietly start waiting again so if you are listening to this and
thinking fine but what do I actually do next let me make that practical do not start with
a platform feature start with one narrow request that enters your business repeatedly
and causes delay because people still handle it through messages memory and local interpretation
that could be leave requests it could be equipment requests it could be onboarding tasks the
specific use case matters less than the pattern you are looking for a process with one clear
trigger one obvious decision path and one painful amount of ambiguity at the front door
then define one measurable outcome not five one for this contours example we used cycle time
reduction because it ties directly to the operating problem a request that used to drift
through email now enters a governed path immediately that is visible that is measurable
and it gives you a way to judge whether the app improved business behavior or just changed
where people click after that map the process in three parts what event starts it what decision
follows it what status language should the whole business share if you cannot answer those
three questions cleanly do not build yet you are still dealing with process fog and the
platform will not fix that for you it will only express it faster once those answers are
clear choose the app type based on the job if your first need is a controlled simple low
friction experience for employees choose canvas canvas is the right front door when adoption
depends on clarity especially for narrow actions like request submission if your primary need is
broad operational visibility across records relationships views and process oversight model driven
maybe the better fit not because it is more advanced but because it is built for a different operating
posture and if you are unsure ask a simpler question are you designing for ease of entry or for
depth of operations that question usually clears the noise then model the data with more discipline
than feels necessary at first that sounds backwards because beginners often want to spend energy
on screens but the cleaner your data verse structure is now the easier everything becomes later
create the request object properly you standardize statuses link the request to the employee and
approval context add structural readiness for future complexity like delegation or country policy
without trying to automate all of it in release one this is the part most people skip and then
they pay for it later next protect scope your first release does not need reminders escalations
advanced routing external integrations in every edge case the business can remember from the last
10 years it needs one thing more than anything else a stable first value moment in contoso that
value moment is very simple and employee submits a proper vacation request into data verse and can
see that it exists with a visible status that is enough to change behavior ship that before you
chase completeness while you are doing that stay intentional about where you build if the app is
still an experiment fine move quickly if the app is about to become part of how work gets done stop
treating environment choice like an afterthought give it cleaner boundaries start as you mean to grow
that one decision saves you from a lot of support and governance paying later and keep your connector
story simple a first app does not need to impress people with integration density it needs to prove
that a better operating path exists the more external complexity you pull in too early the more likely
you are to create cost surprises testing drag and dependency problems before the business has
even validated the basic pattern earn complexity do not frontload it so the implementation path is
not complicated but it does require restraint pick one repeatable request pick one business metric
define event decision and status choose canvas or model driven based on the real job model data verse
cleanly ship the smallest usable release keep environments and connectors intentional then watch
what happens to behavior because if your app idea still sounds vague after all of that there is a good
chance you do not have an app problem yet you have a process design problem that wants to masquerade
as a user interface project and that distinction will save you a lot of wasted build effort so that is
the first architectural move turn structured data into a working front door and use the app type
that fits the behavior you actually need if you want the next layer where this request starts moving
through approvals reminders and delegation without inbox drift listen the next episode because
a form captures intent, but automation is what creates throughput.