Sometimes the right workflow experience is fully public: a registration page, intake flow, or application embedded directly on your website. Other times, the workflow belongs behind a signed-in experience where your system already knows who the user is and what information should be prefilled.
With the new Embed Workflows feature in Intellistack Streamline, teams can support both patterns. You can embed a workflow on a public-facing page with a copy-and-paste iframe snippet, or you can use HMAC authentication on an incoming webhook step to start sessions securely from your own portal or application.
Consider embedding your workflows
- Marketing or program sites - Add a public registration, interest, or intake workflow without sending users to a separate destination.
- Customer portals - Start an application, support, or service workflow with account and contact details already supplied.
- Employee intranets - Launch internal workflows from a signed-in workspace without asking employees to re-enter profile information.
Two ways to embed
Embedded Workflows supports two practical approaches depending on the experience you need to deliver.
Public embed for fast rollout
Public embed is the simpler path. A builder copies the iframe code from the Share drawer and places it on a website, landing page, or other HTML-based surface. The workflow loads directly inside that page, so users can start without being redirected somewhere else.
This works well for scenarios like:
- Public applications
- Event or program registration
- Self-serve request forms
- Intake flows next to supporting content on your site
Secure embed for authenticated experiences
Secure embed is for cases where the surrounding application should control how a session starts. Instead of relying on an open session start, the workflow begins with an Incoming Webhook step that uses HMAC authentication.
That allows your portal or backend to send trusted data into the workflow such as a logged-in user's name, email, account context, or other prefilled values, while still rendering the workflow inside your own page.
Why HMAC matters
HMAC matters when an embedded workflow should be available only through a system you trust.
It does two jobs at once:
- Restricts who can start a session. Only systems that hold your shared secret can launch the workflow, so a workflow meant for logged-in customers, employees, or partners can't be opened by anyone who happens to find the URL.
- Protects sensitive data in transit. HMAC ensures that only your authorized system can send that data into the workflow and that nothing was altered in transit.
That is what makes secure embed a fit for employee hubs, customer portals, partner experiences, and backend-triggered flows. Even if someone discovers the webhook URL, they cannot start the workflow without a valid signature.
How each approach works
The starting point is the same: builders generate an embed snippet from the Share drawer and place the workflow inside their own site or application.
For public embed, the workflow loads in the page and users interact with it directly.
For secure embed, the flow adds a controlled session-start step:
- A builder creates or selects a workflow for embedded use.
- The workflow starts with an Incoming Webhook step configured with HMAC authentication.
- An admin creates the webhook connection in Integrations and provides the generated secret to the development team.
- The customer's application sends a server-side, HMAC-signed request to the incoming webhook endpoint.
- Streamline creates the session with the trusted payload, and the embedded workflow renders inside the customer's page.
What this enables
Together, the two embed approaches give teams room to match the workflow to the surface.
- Marketing or program sites - Add a public registration, interest, or intake workflow without sending users to a separate destination.
- Customer portals - Start an application, support, or service workflow with account and contact details already supplied.
- Employee intranets - Launch internal workflows from a signed-in workspace without asking employees to re-enter profile information.
The result is a better fit across more journeys. Some teams need a fast public embed they can deploy with minimal effort. Others need a more controlled embedded experience tied to their own authentication and application data. Streamline supports both.
A few things to know
There are a few setup basics worth calling out:
- Embedded workflows must start with an Incoming Webhook step or Form step.
- For secure embed, the first step must be an Incoming Webhook step with HMAC authentication enabled.
- HMAC signing happens on the customer's backend, so secure embed requires some development work.
One feature, two rollout paths
What makes Embed Workflows useful is that teams do not have to force every use case into the same model. If the goal is broad access and fast setup, public embed is the right fit. If the goal is controlled session starts and prefilled context from your own application, secure embed with HMAC is the better fit.
In both cases, the workflow stays inside the experience your users already know. Your site remains the front door, and Streamline handles the workflow itself.
Available now
Embed Workflows are available to Intellistack Streamline customers. For setup details, readers can start with the help article on Embedding Workflows on Your Website, review webhook configuration in Setting Up an Incoming Webhook Step in Streamline, and use the developer documentation for HMAC Authentication for Incoming Webhooks when they need the secure path.
