Native module integrations
Learn why Workestra Portals does not require a second customer database or synchronization layer.
Workestra Portals is not a separate portal database connected to Workestra by webhooks. It is the controlled external view of the modules already running your business.
What “native” means
| Workestra module | What the portal uses |
|---|---|
| CRM | The canonical company, primary contact, and invited contact identity |
| Projects | Current projects, phases, tasks, and delivery progress |
| Sales | Current quotations and record-scoped accept or decline actions |
| Finance | Current invoices and record-scoped document access |
| Contracts | Current contract records |
| Subscriptions | Current plans, subscriptions, and permitted self-service |
| Support | Current tickets, customer comments, and selected knowledge articles |
| Calendar | Current meetings and appointments |
Portals owns the presentation, membership, role, section, and exposure policy. It stores a typed reference to an allowed source record—not a copied quotation, invoice, project, ticket, or meeting.
Why this replaces external portal middleware
A standalone portal normally requires:
- Customer and contact synchronization.
- Project, invoice, quotation, and document mapping.
- Webhooks or scheduled jobs to keep copies current.
- A second user and permission directory.
- Reconciliation when delivery or synchronization fails.
Workestra removes that layer. Your team updates the owning module once, and the stakeholder sees the permitted current state without a second publishing step.
Examples:
- Correct a quotation in Sales and the portal resolves the corrected quotation.
- Record an invoice payment in Finance without updating a portal copy.
- Change a project status in Projects and show the current progress.
- Reschedule a meeting in Calendar and expose the current appointment.
- Suspend a portal member without deleting the canonical CRM contact.
One authorization boundary
Every composed request intersects:
- The workspace.
- A published portal.
- An active member of that exact portal.
- The member’s portal role.
- A visible section.
- An active Workestra module entitlement.
- An enabled source policy.
- The exact shared record or approved party-live rule.
Two portals for the same CRM contact can therefore expose different projects, invoices, or support records.
When an external portal may still fit
An external product can still make sense for a marketplace, an anonymous public community, a highly specialized industry application, or a portal whose primary records live across several non-Workestra systems. For organizations already operating in Workestra, the native portal avoids the cost and failure surface of maintaining another system of record.