Integrations on Tealfabric usually span three layers: connectors for external systems, Process Flow for orchestration, and tenant data for inputs and outputs.
This separation is useful because each layer has a clear responsibility. Connectors know how to communicate with external systems. Process Flow knows what should happen and in what order. Tenant data provides the state that flows need to work with.
The pattern is simple, but it can be used to automate surprisingly complex business processes.
Start from a connector capability
Pick a connector that matches your source or sink: REST APIs, files, databases, email, or SaaS applications. Configure credentials in the platform console, then reference the connector from a process step.
For example, imagine a company onboarding new suppliers. A supplier submits a registration form, after which the process needs to:
- Read the submitted information.
- Validate that required fields are present.
- Check the company against an external company registry.
- Create the supplier in the ERP system.
- Notify the procurement team.
- Store the result and any generated documents.
The individual integrations are handled by connectors. The business logic belongs in Process Flow.
This distinction becomes particularly valuable when the same external system is used by several processes. You can reuse the connector without duplicating authentication, API handling, and integration code in every workflow.
Orchestrate with Process Flow
Use Process Flow steps to validate input, call connectors, transform results, and route errors.
A typical integration flow might look like:
Input → Validate → Fetch external data → Transform → Write to system → Notify → Complete
For example, a customer order arriving through an API could trigger a flow that:
- validates the order structure
- retrieves the customer's current information from the CRM
- checks inventory through an ERP API
- creates or updates the order
- sends a confirmation email
- records the outcome in tenant data
The important part is that the flow describes the business process, rather than becoming a collection of API calls.
This also makes flows easier to change. If the company later moves from one CRM to another, the connector can change while the overall process can remain largely the same.
Real-world pattern: turning incoming data into an operational process
A common integration problem is receiving information in one place and needing to turn it into work somewhere else.
Consider a support organization receiving requests through email.
An automated flow can:
- Detect a new message.
- Extract the relevant information.
- Classify the request.
- Look up the customer in the CRM.
- Create a support case.
- Attach the original email and relevant files.
- Assign the case to the appropriate team.
- Notify a human when manual action is required.
Without orchestration, each of these actions tends to become a separate integration or manual handoff.
With connectors and Process Flow, they become one continuous process.
The same pattern applies to many other situations:
- Supplier onboarding: collect supplier data, verify it, create the supplier record, and notify procurement.
- Invoice processing: receive an invoice, extract data, validate it against purchase orders, send it for approval, and update the accounting system.
- Sales operations: capture a new lead, enrich company information, create a CRM record, assign an owner, and schedule follow-up.
- Employee onboarding: create accounts, update HR systems, request equipment, and send onboarding information.
- Customer data collection: request information from a customer, validate the response, transform it into the required format, and distribute it to downstream systems.
- Document workflows: collect files, process their contents, store structured information, and publish the resulting documents.
In all of these cases, the value is not in connecting two systems. The value comes from completing the business process that happens between them.
Make integrations resilient
Real-world integrations fail occasionally. APIs time out, services become temporarily unavailable, files contain unexpected data, and external systems change.
Design flows with this in mind.
Keep side effects idempotent where possible — retries are common in long-running flows. For example, if a flow is responsible for creating a CRM record, it should be possible to determine whether that record has already been created before creating another one.
Validation should also happen before irreversible actions. If an incoming file is missing a required field, it is usually better to stop the flow and request correction than to create partially valid records in downstream systems.
For operations that require human judgment, route the process to a person rather than trying to automate every decision. The flow can pause, request input, and continue when the decision has been made.
This creates an important distinction: automation does not have to mean zero human involvement. It means that humans spend their time on the parts of the process that actually require them.
Combine deterministic steps with AI
Process Flow is also useful when deterministic integration logic needs to be combined with AI.
For example, a supplier may submit a sustainability document as a PDF. The flow can use connectors to retrieve the document, pass its contents to an AI step for extraction, validate the resulting data, and then write structured information to the appropriate system.
The flow remains responsible for the process:
Retrieve document → Extract information → Validate → Store → Notify
The AI handles the part that is difficult to implement with traditional deterministic code, while the Process Flow provides structure, state, error handling, and control.
This pattern is especially useful for processes involving unstructured inputs such as emails, PDFs, free-form text, and customer-submitted documents.
Publish artifacts publicly
Some flows produce files that need to be delivered to customers, suppliers, or other external users.
For example, a process might generate a completed report, a compliance document, or a customer-specific data export. Instead of building a separate file-serving application, the resulting artifact can be exposed through the public docs gateway without duplicating the underlying bytes.
See the Library guide on public file downloads for the full model.
This makes a useful pattern possible:
Collect → Process → Generate → Publish
A single Process Flow can therefore take an input from an external system, perform business logic, generate an artifact, and make the result available to the person who needs it.
Keep the boundaries clear
A good integration architecture does not put everything into one place.
Use connectors for communicating with external systems.
Use Process Flow for deciding what happens, when it happens, and what happens next.
Use tenant data for storing the state and information that the process needs.
Use AI steps when the process involves interpretation, extraction, classification, or other tasks where traditional deterministic logic is insufficient.
Keeping these boundaries clear makes individual components reusable and makes business processes easier to understand, test, and evolve.
The result is more than an integration between two systems. It is an operational process that can run from beginning to end.
Questions? Ask in the Library or open a support thread from your tenant console.