I’d never used Lovable before this experiment.
Rather than build a random standalone app, I wanted to test something closer to the Dynamics projects I actually work on:
Can Dynamics 365 stay the system of record while Lovable provides a more focused experience for a specific workflow?
So I connected Lovable to a Dynamics 365 CE demo environment and built a Deal Review experience around live Opportunity data.
The goal was not to rebuild the Opportunity form with prettier buttons.
Dynamics already has an Opportunity form. We’re good there.
What This Is For
The Deal Review experience is designed to answer one question:
What do I need to know about this deal, and what needs my attention right now?
Dynamics still owns the data:
- Opportunities
- Accounts
- Contacts and stakeholders
- Activities
- Notes
- Revenue
- Close dates
- Sales stages
Lovable sits on top and gives the user a more focused way to understand and act on that information.
Think:
Dynamics = system of record
Lovable = tailored experience layer
When I Would Use This — and When I Wouldn't
I would consider this approach when a specific user only needs a small part of the overall CRM experience.
For example:
- A seller reviewing one deal
- A sales leader scanning for at-risk Opportunities
- An executive reviewing Account health
- A customer or partner completing a limited external process
I would not use it simply because someone thinks the standard Dynamics UI isn't exciting enough.
Model-driven apps already give us security, relationships, auditing, business logic, automation, ALM, activities, and a lot more.
Rebuilding all of that because we wanted nicer cards sounds like a fantastic way to create unnecessary work.
Before You Start
My basic pre-flight checklist looked like this:
- Use a demo Dynamics environment, not client production data.
- Decide which record you're starting with. I recommend one Opportunity.
- Confirm the Dynamics/Dataverse connection from Lovable.
- Keep Dynamics as the source of truth.
- Don't create a separate database just for the UI.
- Don't use fake frontend data to make the demo look smarter.
- Make sure you can prove both read and write operations before expanding the app.
And most importantly:
Start small.
Do not be a hero and connect half of Dataverse on day one.
How I Built It
1. Connect Lovable to Dynamics 365
I started by connecting my Lovable project to a Dynamics 365 CE demo environment.
The first goal wasn't to build anything fancy.
I simply wanted to prove:
- Lovable could retrieve a Dynamics Opportunity.
- Related CRM information could be displayed.
- An update made through the new experience could write back to Dynamics.
Once that worked, the architecture was proven.
Test This Before Continuing
Pick one simple field such as:
- Estimated Revenue
- Estimated Close Date
- Next Step
Update it through the Lovable experience.
Then open the Opportunity in Dynamics and verify the actual CRM record changed.
Future You will thank you for validating write-back before building 14 more features.
2. Build a Focused Deal Review — Not Another Opportunity Form
My first version included information like:
- Opportunity value
- Close date
- Sales stage
- Next step
- Stakeholders
- Recent activities
- Open activities
- Notes
But I quickly realized that simply displaying those fields wasn't very interesting.
Dynamics already does that.
So the next goal became:
Turn the CRM data into something the seller can actually act on.
3. Add Stakeholder Coverage
For my demo Opportunity, I added a realistic Buying Committee:
- Marketing Champion
- Technical Buyer
- Procurement contact
- No Economic Buyer
Instead of only listing those Contacts, the Deal Review can interpret the coverage:
- ✅ Champion identified
- ✅ Technical buyer identified
- ✅ Procurement involved
- ⚠️ Economic buyer not identified
That is much more useful than making the seller inspect several Contact records themselves.
4. Give the Opportunity Realistic Activity Data
A perfectly healthy Opportunity is not particularly helpful for demonstrating Deal Review.
So I added some realistic activity history:
- Discovery call — completed
- Branding review — completed
- Revised pricing proposal — overdue
- Budget approval follow-up — open
- Technical review — upcoming
- Executive pricing review — upcoming
I also added notes with context around the deal.
Now the experience had enough CRM information to surface useful signals such as:
- Pricing proposal overdue
- Economic buyer not identified
- Close date approaching with executive approval outstanding
That's where the app stopped feeling like a different CRM form and started feeling like a purpose-built experience.
5. Add Actions That Write Back to Dynamics
I didn't want this to be read-only.
Actions from the Lovable experience should still affect the real Dynamics records.
Examples include:
- Update the Opportunity close date
- Update estimated revenue
- Add a note
- Create a follow-up activity
- Complete an existing task
After the action succeeds, refresh the data from Dynamics.
The user gets the tailored experience.
Dynamics still owns the record.
No second CRM required.
6. Add Explainable Deal Health
The next piece was Deal Health.
I deliberately avoided creating some mysterious:
Deal Score: 72
Okay. Why 72?
Instead, I prefer a simple Green / Amber / Red status supported by actual reasons.
Useful signals can include:
- Is an Economic Buyer identified?
- Is there a Champion?
- Is the deal single-threaded?
- How many days since the last activity?
- Is there a defined next step?
- Are activities overdue?
- How long has the deal been in its current stage?
- Has the close date moved?
- Is the close date approaching?
For example:
🟠 Amber
- Economic Buyer not identified
- No activity in nine days
- Next step is defined
The color tells the sales leader where to look.
The explanation tells them why.
7. Use the Same Data for a Different Role
This is where the concept became much more interesting to me.
A seller is asking:
What should I do next on this Opportunity?
A sales leader is asking:
Which Opportunities need my attention?
Same Dynamics data.
Different experience.
So I expanded the concept into a Pipeline Health view that can surface:
- Total open pipeline
- Green / Amber / Red deals
- Deals needing attention
- Stakeholder gaps
- Activity risk
- Missing next steps
- Upcoming close dates
An executive can scan the pipeline, select an at-risk deal, and then drill directly into the detailed Deal Review.
Where I'm Taking It Next: Account Health
The next use case is one I would legitimately want on a real implementation.
Account Health
For an Account, I want to see:
- Won Opportunity Value
- Open Pipeline
- Active Opportunities
- Largest Open Deal
- Last Activity
- Relationship Coverage
And eventually:
Actual Revenue Billed / Invoiced
This is where I would bring in Business Central.
Dynamics tells me what Sales has won.
Business Central tells me what we've actually invoiced.
Those are not always the same number.
Eventually, I'd like an Account view that looks something like:
- Won Business: $1.4M
- Actually Invoiced: $980K
- Open Pipeline: $425K
Now we're combining CRM and financial data around the question an Account owner or executive actually cares about.
Common Gotchas
Don't Trust the UI Just Because It Looks Convincing
AI-generated applications can look finished before the underlying integration is finished.
Validate things like:
- Did that Contact actually get created in Dynamics?
- Is that overdue warning using a real Dynamics due date?
- Did that note actually write back to the Opportunity?
- Is the Deal Health logic calculated or hard-coded?
Ask me how I know.
Don't Rebuild Dynamics Feature by Feature
Once things start working, it's very easy to keep adding.
Forecasting! Dashboards! Portals! AI! More tables!
No.
If Dynamics already handles something well, leave it there.
Consultant law #12: just because you can build another dashboard does not mean the world needs another dashboard.
Validation Checklist
Before calling the experience finished, I want to prove the full loop:
- [ ] Opportunity exists in Dynamics
- [ ] Lovable retrieves the real record
- [ ] Related stakeholders and activities load correctly
- [ ] Health signals are based on actual CRM information
- [ ] An update from Lovable writes back to Dynamics
- [ ] A change made directly in Dynamics appears in Lovable
- [ ] Warnings disappear when the underlying issue is resolved
- [ ] No important business data exists only in the frontend
That last test is important.
If I add an Economic Buyer, I expect Economic Buyer Missing to disappear.
Seems obvious.
Still test it.
The Real Scenario
Imagine a $500K Opportunity expected to close this month.
Dynamics shows:
- A Champion
- A Technical Buyer
- No Economic Buyer
- Pricing overdue
- Last activity two weeks ago
- An upcoming close date
All of that information already exists.
The Deal Review turns it into:
🔴 Needs Attention
- Economic buyer not identified
- No recent activity
- Pricing is overdue
- Close date approaching
A sales leader sees the Opportunity in Pipeline Health, clicks into it, and lands in the detailed Deal Review.
Same CRM.
Same records.
Less work required from the user to understand what is actually happening.
The Takeaway
I originally started this because I wanted to experiment with Lovable.
The part that became much more interesting was the architecture behind it.
I'm not particularly interested in answering:
Can Lovable replace Dynamics 365?
I don't need it to.
The question I find much more useful is:
Where could a highly focused experience make one Dynamics workflow significantly easier?
A seller doesn't necessarily need the same experience as a sales leader.
A sales leader doesn't necessarily need the same experience as an executive.
And none of those experiences require us to throw away the Dynamics platform underneath them.
That's what I'm going to keep experimenting with.
Next up: Account Health — and eventually bringing actual invoiced revenue from Business Central into the same experience.