Creating a New Dynamic Orchestration Service — No Code, Just Instructions

One of the things we keep coming back to with PolySaaS is this: integrations shouldn’t require writing a new service every time you need one. They should be configured, not coded.

In this week’s demo, we walk through exactly that — standing up a brand-new Dynamic Orchestration Service against Odoo’s Products page, live, with nothing but an orchestration instruction.

What’s happening in the demo

We start on Odoo’s Products page — an out-of-the-box screen, untouched. Behind the scenes, PolySaaS’s Odoo passthrough is watching every request that flows through it, and the Dynamic Orchestration Service is matching that traffic against an instruction we’ve configured.

The instruction itself does the real work:

• Pattern matching on the URL path and action path, so PolySaaS knows exactly which requests to intercept
• GET request direction, paired with an Atomic Service that captures the GET response as it passes through
• Filtering parameters — an event key and description — that scope which records get picked up
• Callback data written out, which lands as structured records in a mailbox output for downstream use

Run it, and ten product records flow straight out of Odoo into the mailbox — no Odoo module installed, no view record touched, no code shipped into the SaaS application itself. Odoo stays exactly as it ships.

Why this matters

This is the GET-based version of PolySaaS’s first orchestration action type: extract data from one SaaS and feed it to another. We already had a POST-triggered example of this pattern; this demo fills in the GET side, which is the more common shape for “pull data out on a schedule or on demand” integrations.

It also doubles as a debugging tool in its own right — the raw Atomic Service output gives full visibility into exactly what was captured and why, which matters a lot when you’re configuring pattern-matching rules against a SaaS UI you don’t control.

What’s next

This extract-and-capture step is done — the mailbox side is publishing cleanly. The next piece is the consumer: wiring that mailbox output through to a destination SaaS so the full extract-to-feed pipeline is closed end to end.