Flowlith Iris is a customer-facing sales and service assistant. She can explain your business, ask useful follow-up questions, and use the specific external operations you have connected and enabled. She is not a replacement for your CRM, ERP or hospital information system, and adding an API key does not grant her every capability in that system.
Three kinds of capability
| Capability | What is available | What you must provide |
|---|---|---|
| Conversation and business knowledge | Answer questions, explain policies, collect details and follow taught procedures | An approved, launched business, saved business information, useful references and a connected customer channel |
| Live business-system work | Look up current records or perform an approved operation | A compatible API, webhook or MCP tool; scoped credentials; backend authorization; a tested, active Action |
| A feature your backend does not offer | Not created automatically by Iris | Your developer or vendor must implement the missing operation, or your team must handle it |
The integrations below are examples of what can be built, not claims that a named CRM, ERP or HIS is already connected. See Backend requirements for the interface your provider must supply.
Conversation and knowledge
With the appropriate business setup, Iris can:
- Answer customer questions from approved business facts, FAQs and reference material.
- Explain products, service areas, opening hours, policies and next steps without needing access to your operational system for every answer.
- Ask follow-up questions, gather the information needed for a task, and continue the same customer conversation.
- Follow taught procedures and your preferred tone and language. Test the languages and terminology your customers actually use; accuracy is not guaranteed.
- Use shared business notes and learn reusable lessons. Shared knowledge is not a live stock database, a customer directory or proof of an external transaction.
- Understand supported incoming photos and voice notes. Customer document reading is availability-dependent. Supported formats and channel differences are in Channels and media.
These are customer conversations on connected WhatsApp, Instagram, Messenger or your website integration. The dashboard's customer preview is a separate test conversation using applied knowledge; it is not an administrative chat or a view of real customers' conversations.
What a CRM can enable
A CRM manages customer relationships. Connect narrow tasks rather than exposing the whole account:
| Example customer task | What Iris could do after integration | Backend responsibility |
|---|---|---|
| “Can your team contact me about this service?” | Gather the agreed details and submit a lead after confirmation | Validate the fields, deduplicate the lead and return a reference |
| “I need help with my order.” | Create a support ticket with the agreed summary | Attach it to the correct authorized customer and return a ticket ID |
| “Has my support request been resolved?” | Read the current ticket status | Verify customer ownership before returning only the permitted status |
| “Please update my delivery contact.” | Propose and submit an allowed contact change | Verify the customer, limit editable fields and record the change |
Remembering a name in a conversation does not create a CRM contact. Saying “the team will follow up” does not create a ticket or notify staff. Those outcomes need a working Action and a confirmed result.
What an ERP can enable
An ERP manages operational records such as inventory, orders and billing. Possible connected tasks include:
- Check current stock, product availability or a customer-visible price from the authoritative source.
- Retrieve an authorized customer's order, delivery or invoice status.
- Submit a reservation, service request or permitted order change after the customer confirms the details.
- Give a customer an approved payment link returned by their business system, without handling card details in chat.
Your ERP must calculate totals, tax, discounts, stock reservations and eligibility itself. A customer message, uploaded invoice or screenshot is not proof of payment. Do not ask Iris to infer a successful transaction from those materials.
Actions are short request/response operations, not a background workflow engine. For a slow job, your backend should return an operation reference and an explicit pending status, then offer a separate read-only status check. “Accepted” or “queued” is not “completed.”
A stock lookup alone does not create a purchasing workflow. An invoice-status lookup alone does not collect a payment or issue a refund. Configure and test each operation separately; a multi-step business transaction should be coordinated by your backend.
What a HIS can enable
Here HIS means a hospital information system. The same integration mechanism can support appropriate non-clinical administrative workflows, for example:
- Explain approved visiting hours, locations, administrative requirements and contact routes from public information.
- Check appointment availability through an approved scheduling endpoint.
- Request, reschedule or cancel an appointment through a tested operation, after identity checks and confirmation.
- Check a permitted administrative request's status or request staff assistance through an approved workflow.
These are integration possibilities, not a built-in clinical connector. Your organization must approve the use case and what data can be shared before connecting patient-related operations. Use fictional records for setup and testing.
The HIS or your integration backend must verify the person and their authority to access each record. A WhatsApp number, a typed patient ID, name or date of birth is not sufficient authorization by itself. Use your organization's approved secure verification flow outside ordinary chat. Never request login codes, passwords or full medical records as a workaround.
Return only the information needed for the approved administrative task. Do not put patient records in shared business knowledge. This guide does not establish a clinical, diagnostic, prescribing, emergency-response or compliance capability. Keep clinical decisions and urgent care with the appropriate professional service.
A connected operation, end to end
This is an illustrative appointment request, not a ready-made integration. The backend must establish customer scope and enforce availability and booking rules first.
Customer: Is there an appointment on Tuesday afternoon?
Iris: [Uses the approved availability Action.]
Backend result: Two eligible slots, with stable slot references.
Iris: [Proposes that exact slot with the booking Action; no booking is sent yet.]
Iris: There is a 3:00 pm slot. Would you like me to book it?
Customer: Yes, book the 3:00 pm slot.
Iris: [Confirms that same booking proposal through the approved Action.]
Backend result: A confirmed booking reference and time.
Iris: Your appointment is confirmed for 3:00 pm. Reference: DEMO-4821.
Only show the final confirmation if the system actually confirms it. If the request times out, Iris must not invent success or send another booking blindly. Check the original request in the destination system using your recovery workflow.
Customer confirmation is permission for the proposed change; it is not proof of identity or a replacement for backend authorization. A changed slot, amount, recipient or other material detail requires fresh confirmation.
What connecting MCP changes
There are two separate connections:
- Your AI app → Flowlith: an authenticated owner can ask the app to help manage business setup, teaching and Actions. This uses Flowlith browser sign-in.
- Iris → your external MCP tools: customer conversations can use only the tools you have selected, reviewed, tested and activated as Actions. This uses the system's supported server credentials, not your AI app's Flowlith sign-in.
Connecting your AI app does not attach its other plugins, files or accounts to Iris. An owner management tool is not a customer-facing tool. Read How MCP connects for both flows and exact setup steps.
What is not included automatically
- A universal, preconfigured connection to every CRM, ERP or HIS vendor. Compatibility must be checked against the actual API or tool contract.
- Direct database access, SQL execution, shell commands, browser automation or arbitrary web browsing in customer conversations. Do not expose broad administration or “run anything” tools through your backend either.
- Automatic access to every tool on a connected MCP server, or permission to install new customer tools from a chat message.
- Interactive OAuth login to external systems through customer Actions. Use the supported key/token connection or an approved integration backend.
- A hosted website widget: your website needs its own interface and secure backend integration.
- A built-in bulk campaign, scheduled-reminder or outbound-email engine. An explicitly approved Action may request a permitted workflow from a separate service that provides it; sending, scheduling and consent enforcement belong to that service.
- Voice calls, generated voice replies, image/video creation, or automatic outgoing file delivery as built-in chat features. Understanding an incoming voice note or photo is not the same as generating or sending media.
- Automatic cross-channel customer identity linking, patient verification, payment processing, or a staffed live-handoff inbox. Your authorized backend and team must supply those workflows where needed.
- Guaranteed correctness or successful third-party delivery. A connected badge, successful preview or polite reply is not proof of an external result.
Define one useful first journey
Give your developer or AI assistant this non-secret brief. It makes the missing work visible before anyone promises that Iris can do it.
System: [CRM / ERP / HIS / custom backend, name and version]
Customer task: [one specific outcome]
Channel: [WhatsApp / Instagram / Messenger / website]
Facts Iris may answer from our approved knowledge:
[public facts and reference material]
Read operation needed:
[name, documented endpoint or MCP tool, required inputs, allowed outputs]
Write operation needed, if any:
[name, exact effect, customer confirmation, confirmed result]
Identity and permission checks performed by our backend:
[how the current customer is verified and authorized for this record]
Test fixture and success evidence:
[fictional account, expected record/reference, who checks the destination]
Failure and human route:
[what Iris should say, how the original request is checked, who helps]
Never include credentials, real patient/customer records or login codes.
Do not claim a connector or capability is ready until this journey passes.
Next: Backend requirements → MCP connections or API and Action examples → test the real customer channel separately.