Type 4 Dynamic Orchestration: Replacing an Odoo Screen Without Touching Odoo
Here’s a demo of PolySaaS’s Type 4 orchestration in action — the pattern where, when a SaaS app opens a page, PolySaaS intercepts it and serves its own branded page instead. No module installed, no code written into the SaaS application itself. This one builds that out end to end against Odoo’s “New Vendor” screen.
What’s happening in the demo
When Odoo would normally open a blank “New Vendor” form, PolySaaS intercepts the request and serves its own branded page instead. From there:
- Criteria capture — the operator enters product line, region, and price range
- Suggested shortlist — a curated/AI-assisted directory returns candidate vendors, clearly labeled as suggestions rather than a live web search
- Select and bind — picking a row fills the vendor form, including a linked main contact when one’s available
- Save to Odoo — writes the vendor as a company partner, plus the linked contact record
- Event publish — once saved, PolySaaS publishes the new vendor to a topic so other connected apps can pick it up on their own
Odoo stays the system of record the entire time. PolySaaS never writes a module or a view into Odoo — it rewrites what passes through the proxy, the same way it already rewrites CSS and layout elsewhere in the platform.
Why this matters
This is what “no-code integration” should actually mean: a new screen, a new workflow, a new data flow into your ERP — without a developer touching the SaaS application at all. Every rule that governs this behavior is configuration, not code, which is what lets the same pattern scale across different screens and different tenants without a rebuild each time.
What’s next
Type 4 New Vendor Assist is done end to end — branded page, AI-assisted shortlist, Odoo write, event fan-out. Next up: swapping the curated demo directory for a real web/AI-backed vendor search.
Want to see this running against your own stack?
The Founders Beta Circle gets you full access to PolySaaS — any number of apps, bundled or not — for $10/mo for six months while we build this out together.
**Comment from Claude (Anthropic):**
What stands out to me about this demo isn’t just that an Odoo screen got replaced — it’s *where* the replacement happens. The rewrite lives entirely in PolySaaS’s own proxy layer, with zero code, modules, or config touching Odoo itself. That’s a meaningfully different claim than most “customization” tools make.
For SaaS vendors and investors watching this space, that distinction matters for a few concrete reasons:
– **No fork, no drift.** Because nothing is installed into the underlying app, there’s no custom module to maintain against every future Odoo (or any other SaaS) release. The vendor’s core product stays stock and upgradeable; the customization layer is independent and versioned separately.
– **Multi-tenant customization without multiplying codebases.** A module registry keyed per tenant means each customer can get their own reformatted screens, branding, and field logic without PolySaaS — or the SaaS vendor — maintaining N different forks of the same app.
– **This generalizes past Odoo.** The same proxy-rewrite mechanism that swapped a field and added branding here is, in principle, the same mechanism that handles the other three orchestration types (extract/feed, capture-correlate, mid-stream refine). That’s one architecture doing UI-level, data-level, and workflow-level intervention — which is a different pitch than point-integration tools that only move data between systems.
– **It’s a wedge into “platform,” not just “integration.”** The moment you can rewrite what a user sees and how they interact with a screen — not just the data flowing behind it — you’ve crossed from connecting SaaS products into shaping how they’re consumed. That’s the application-platform positioning, made concrete rather than asserted.
The unglamorous part — screen recording tools clipping at 2 minutes, DaVinci overdub refusing to cooperate — is a reminder that shipping the proof is often harder than building the thing being proved. Worth noting for anyone judging execution speed here: the underlying engineering was done well before the last mile of “show it to people” caught up.
Dueling AIs, Grok is offereing the following:
**Opinion: What Type 4 Dynamic Orchestration Actually Buys You**
Most “integration platforms” still ask you to choose a false tradeoff: either live inside the vendor’s UI and accept whatever blank form they shipped, or leave that UI and rebuild the same workflow in a middleware canvas. Type 4 is PolySaaS refusing that tradeoff.
On the surface, the milestone looks modest: a New Vendor flow in Odoo that is not Odoo’s native form. Underneath, it is a different operating model. An Instruction on a real action path (`/odoo/vendors/new`) swaps the page, runs atomics, binds a shortlist, writes `res.partner` (company + optional contact), and publishes into Vendors and Contacts topics—without a special-case branch in the Odoo handler and without forking Odoo. Odoo remains the system of record. PolySaaS remains the place orchestration is defined, observed, and extended.
That is the part investors and serious operators should sit with.
—
### Why this is not “another Zap”
Zaps and iPaaS recipes fire *after* something already happened in an API or a webhook. Useful, but they rarely own the moment the user is staring at a bad screen. Type 4 owns that moment. The user still believes they are “in Odoo.” The green bar tells the operator the path is live. The save still lands in Odoo. The event still shows up under Captured Topics. Same gesture language whether the next endpoint is Mattermost, Nextcloud, or a pure API app like Slack.
The economic claim is simple: **configuration on an action path beats custom code per product screen.** One Instruction model, reusable atomics, topics as the fan-out surface. When the fifth SaaS shows up, you do not invent a fifth integration style—you attach another path and another consumer.
—
### Scenarios that are awkward for everyone else
**1. Replace a toxic native screen without a vendor roadmap**
Procurement wants a guided vendor intake; Odoo’s partner form is generic and slow. Waiting on Odoo’s product team is measured in quarters. With Type 4, the tenant gets Assist, criteria, shortlist, bind, and save on the *same URL the menu already uses*. No module install debate. No “please don’t upgrade, we patched the form view.”
**2. Dual write without dual UI**
Company goes to Vendors; person goes to Contacts; both are real topics, not a log line in a black box. Downstream can notify Mattermost, open a HubSpot task, or stay silent—**without** the Assist page hardcoding those apps. The page publishes news. Consumers decide who listens. That separation is what keeps demos honest when the next subscriber asks for Slack instead of email.
**3. Same operator chrome, different plumbing**
Self-hosted Odoo can be learned and certified under Native, then run under Passthrough with the bar. SaaS-only Slack does not need a fake browser prison; slash command → mailbox → Instruction → atomic still lights the same orchestration story. Competitors either force everything through brittle UI scrape or force everything into API-only and abandon the in-app moment. PolySaaS keeps one mental model: path, instruction, atomic, feedback.
**4. “Don’t touch the core” as a sales feature**
IT signs off faster when you can say: we did not modify Odoo, we did not fork the handler for vendors, customer-create stayed frozen. Compliance and upgrade anxiety are not slideware; they are why mid-market deals stall. Type 4 is evidence you can change *behavior* at the edge of the path without owning the vendor’s codebase.
**5. Demo in one sitting**
Investors do not need a architecture novel. They need: open New Vendor → not the blank form → find suppliers → bind → save → see it under Vendors. That sequence is the product. Everything else is commentary.
—
### What this signals to investors
– **Expansion path:** every high-friction screen in a bundled app is a candidate for Type 4, not a custom project.
– **Gross margin shape:** more value per tenant from Instructions and atomics, not from one-off scripts.
– **Defensibility:** the hard part is not “call Odoo’s API.” It is owning path identity, passthrough trust, and a uniform orchestration surface across mixed hosting models.
– **Narrative discipline:** capture once, orchestrate everywhere, was a slogan; Type 4 is a recorded instance of it on a real ERP path.
Risks remain real: path fragility, auth edges on pure SaaS, and the need for ruthless freeze discipline so agents do not “helpfully” hardcode the next screen. Those are execution risks, not proof the category is empty.
—
### What this signals to subscribers
You are not buying a prettier Odoo theme. You are buying the right to **put your process on the glass** where your users already work, keep the system of record authoritative, and route the consequences through topics you control. When the business says “we need a different new-vendor experience by Monday,” the answer can be an Instruction and an atomic—not a statement of work.
—
### Closing opinion
The industry is full of tools that integrate systems in the basement. Type 4 is about changing what the user sees on the main floor *without* moving the foundation. If PolySaaS can repeat that pattern across a handful of painful screens—and keep Native, Passthrough, and API triggers under one operator language—the milestone is not a blog trophy. It is the first clear picture of a company that sells **orchestration at the action path**, not another connector catalog.
That is harder to copy than a template gallery. It is also the only story worth telling if the goal is durable software, not a feature race.
—
Grok