In my first Lovable + Dynamics 365 experiment, I built a Deal Review experience for sellers and a Pipeline Health view for sales leaders.
That led me to a more interesting question:
What happens when the person interacting with Dynamics data isn't a Dynamics user at all?
For round two, I built a customer-facing Deal Room on top of the same Dynamics 365 CE environment.
The customer never needs to see Dynamics.
Dynamics still owns the records.
What This Is For
The Customer Deal Room gives an external customer a simple place to see and act on the parts of an engagement that actually involve them.
Think:
Dynamics = system of record
Lovable = customer-facing experience
The customer sees things like:
- Joint milestones
- Due dates
- Upcoming actions
- Customer-facing contacts
- Shared updates
They do not see the entire Opportunity record sitting behind it.
That distinction is pretty important.
When I Would Use This — and When I Wouldn't
I could see this pattern being useful for workflows like customer onboarding, renewals, implementation milestones, approvals, partner processes, or document collection.
Basically, situations where an external user needs to participate in a Dynamics process without needing access to Dynamics itself.
I would not use this as an excuse to expose the Opportunity table to the internet and hope for the best.
A working demo and a production security model are two very different things.
Please do not learn that one the exciting way.
Before You Start
Before building the customer experience, I wanted a few things to be true:
- Dynamics/Dataverse remains the source of truth.
- The customer experience only exposes information appropriate for the customer.
- Customer actions write back to real Dynamics records.
- Internal sales data stays internal.
- The first test uses one Opportunity and a very small number of actions.
- I can prove both directions of the integration before adding more functionality.
Do not be a hero.
One customer. One Opportunity. One write-back action.
Get that working first.
How I Built It
1. Start With the Existing Dynamics Process
I reused the same PetWellClinic Opportunity from my first experiment.
Dynamics already contained the Account, Opportunity, Contacts, activities, dates, and notes.
I didn't need a second customer data model.
Instead, the Customer Deal Room pulls the appropriate pieces from the existing process and presents them differently.
The question changed from:
What does the seller need to know?
to:
What do we need to do together to move this engagement forward?
2. Build a Joint Action Plan
The main part of the experience is a customer-friendly action plan.
For my demo, the journey looks something like:
- Discovery completed
- Branding direction approved
- Revised pricing delivered
- Budget approval
- Technical review
- Executive pricing review
- Final agreement
- Project kickoff
The underlying activities still live in Dynamics.
The customer just gets a much simpler view of them.
That's exactly what I wanted.
3. Let the Customer Actually Do Something
A customer portal gets a lot less interesting if it's just another place to read status updates.
So I added customer actions.
For example, the customer can mark:
Confirm final budget approval
as complete.
That action updates the underlying activity in Dynamics.
The customer sees the milestone move forward, while the internal team sees the same updated record in CRM.
No separate task list to reconcile later.
Future You will thank you.
4. Let Customer Updates Flow Back Into CRM
I also wanted the customer to be able to submit an update.
For example:
Budget has been approved. We're ready for the executive pricing review.
That update gets written back to the Opportunity as a Dynamics record rather than living only inside the customer interface.
Now the communication becomes part of the CRM process instead of another piece of context sitting in someone's inbox.
5. Be Very Intentional About What the Customer Does Not See
This ended up being one of the most important parts of the experiment.
My internal Deal Review knows things like:
- Deal health
- Stakeholder coverage
- Missing economic buyer
- Internal sales activities
- Pipeline risk
- Sales strategy
The customer absolutely does not need to see that.
Their experience gets things like:
- Shared milestones
- Relevant contacts
- Due dates
- Customer actions
- Approved updates
Same Opportunity.
Very different view.
Consultant law #12: "the API returned it" is not a security strategy.
For a real implementation, frontend hiding alone would not be enough. Authentication, authorization, record access, API permissions, and server-side filtering would all need to be designed intentionally.
Ask me how I know.
Common Gotchas
The first big one is accidentally treating the customer experience like a prettier Opportunity form.
Don't.
The entire point is that the customer should see less, not more.
The second is trusting the UI because something disappeared from the page.
If an internal note is hidden visually but the customer-facing API can still retrieve it, you haven't solved the security problem.
And finally, make sure the write-back is real.
If a customer marks a milestone complete:
- Did the Dynamics activity actually update?
- Did the correct record update?
- Did the internal experience reflect the change?
- Does a refresh still show the correct status?
Screenshots are not integration testing.
Validation Checklist
Before I'd call this working, I want to prove:
- [ ] Customer-facing data comes from Dynamics
- [ ] Internal-only information is not included in the customer experience
- [ ] A Dynamics update appears in the Customer Deal Room
- [ ] A customer milestone update writes back to Dynamics
- [ ] A customer-submitted update creates the intended Dynamics record
- [ ] Refreshing the app does not lose the change
- [ ] No important engagement data exists only in the frontend
- [ ] The security model is clearly separated from the demo UI
A Real Scenario
Imagine a customer is in the final stages of a proposal.
Marketing has approved the direction.
Pricing has been delivered.
The remaining steps are budget approval, technical review, executive review, and final agreement.
Internally, the seller may care about stakeholder coverage, pipeline risk, and deal health.
The customer doesn't.
They see:
Budget Approval — In Progress
They complete it.
Dynamics updates.
They add:
Budget approved. Ready for executive review.
The internal team sees that update back in CRM and continues the process from there.
Same Dynamics process.
Two completely different experiences.
The Takeaway
My first experiment was about creating different internal experiences on top of Dynamics data.
This one pushed the idea outside of CRM.
The interesting question became:
Can someone participate in a Dynamics business process without feeling like they're using Dynamics at all?
For certain workflows, I think that's where this pattern gets much more interesting.
Dynamics can continue handling the data, relationships, business process, and automation underneath.
The customer gets an experience built around the handful of things they actually need to see and do.
That's a much more interesting use of a custom experience layer than simply making a CRM form look different.
Next up, I want to take this in another direction entirely: combining Dynamics 365 sales data with actual invoiced revenue from Business Central in one Account Health experience.