WebApp portal flow
Login → content → form → workflow → CRM
Partner Portal · apps.acme.example
Acme Partner
Sign in to continue
session issued · secure cookie · tenant acme-ops
User-facing surfaces
“WebApps are the front door. Workflows are the engine. Everything else connects through them.”
Platform
WebApps — publish experiences backed by controlled automation
Customer and partner intake on your brand—forms, portals, and webhooks that trigger controlled workflows on the same platform as CRM and ops, not a drifting landing page beside back-office reality.
Adoption context
- You need this when
- Customer, partner, or employee intake must trigger real back-office workflows on your brand—not a form beside CRM reality.
- Often bundled with
- Integrations for live workflows on one platform.
- Not required if
- Internal-only triggers (API, schedule, email parser) cover your first workflow without a public portal.
Related workflow: Customer & vendor intake · Adoption path
You design the experience. Workflows handle the logic. The platform handles hosting, versioning, logging, and release control.
Teams usually split this across a frontend for forms, a backend API for business rules, separate webhook endpoints for partners, and another pipeline for file uploads—WebApps collapse that into one publishable surface with one automation backend.
A WebApp can be a customer form, a partner webhook endpoint, a branded portal page, or a document review experience. Each links to ProcessFlow on the same platform as connections and Datapools.
- Publish forms, portals, webhooks, and review experiences—without a separate app stack per use case
- One publishable surface with one workflow backend—faster to ship and fully scoped to your account
- Browser pages, webhooks, callbacks, live connections, and document viewers in one model
- Custom HTML, CSS, and JavaScript or schema-driven component library with version-pinned CDN delivery
- Immediate responses for speed; queued work and live streaming for scale and live UX
- JSON, redirect, custom HTTP, session cookies, and HTML response patterns
- Multipart and chunked file uploads; signed download delivery with expiry
- Versioned drafts, explicit publish, execution logs, content security rules, and webhook signature support
Production patterns
Portals, webhooks, uploads, and APIs—one surface model behind each.
End-to-end flow
Mobile login, portal content, form submit—workflow pushes to CRM.
A partner signs into a branded portal on your domain, reviews onboarding status, completes a vendor intake form, and submits to the Tealfabric WebApp. The workflow validates, enriches from a Datapool, calls CRM connections, and returns a redirect—with full request and execution logs.
WebApp portal flow
Login → content → form → workflow → CRM
Partner Portal · apps.acme.example
Acme Partner
Sign in to continue
session issued · secure cookie · tenant acme-ops
03 · Capabilities
Surfaces without scattered tools—backend included, ship with confidence.
Faster to ship than separate frontend and API projects; easier to operate with versioning, publish control, and per-request execution logs.
WebApps are not only mini websites—each type defines how the outside world connects. Customer forms, partner webhook endpoints, branded portal pages, and document review flows share one publishable model.
page · webhook
callback · viewer
one publish model
Browser pages, webhooks, callbacks, live connections, and document review.
Surface types
One publishable model—browser pages, inbound events, callbacks, live connections, and document review.
WebApp
Browser pages—forms, wizards, self-service portals, internal tools
surface
Webhook
Inbound HTTP from payments, CRM events, and partner callbacks
surface
Callback
Structured callback endpoints with JSON-oriented responses
surface
WebSocket
Low-latency, two-way scenarios where the model fits
surface
Document viewer
Collaborative document review and annotation experiences
surface
Platform connections
WebApps are the front door—workflows, data, and connections do the work behind each request.
ProcessFlow
User input or webhook payload becomes workflow input; step output drives the response
linked
Integrations
Workflows call configured CRM, email, storage, and API connections
linked
Datapools
Workflows read and write operational data from the backend
linked
Platform API
API-style WebApps map HTTP paths to workflow logic or proxy authenticated calls
linked
File storage
Uploads land in platform storage and are available to workflow steps
linked
Public file delivery
Signed links with expiry, download limits, and policy metadata
linked
Security & trust
Isolation, content rules, and signed delivery—built into how WebApps publish and respond.
Account isolation
Every WebApp and execution scoped to your organization
Content security policy
Per-app rules for what scripts and assets may load
Referrer policy
Control how browsers send referrer information
Webhook signature support
Raw body capture for provider signature verification
Signed download links
Time-limited, protected file access
Role-gated management
Create, publish, and delete limited to authorized platform admins
vendor-intake · response contract
immediate · queued · redirect
Synchronous response
HTTP 200 · 142 ms
{
"ok": true,
"record_id": "dp_2841",
"validation": "passed"
}Simulated — same WebApp, different response patterns per workflow outcome
Fits the platform
WebApps are what users and partners interact with. ProcessFlow is business logic. Integrations call external systems. Datapools hold structured data. Operations gives cross-platform visibility alongside workflow and connection logs.
Publish on your brand
See WebApps with workflow backends, webhooks, and versioned publish.
We walk through portal forms, partner webhooks, file uploads, custom domains, execution logs, and CRM connection steps—on the same platform as access controls and Datapools.
Pilots start with one live workflow—system connections, steps, and full history.