--- title: "Business workflows: two services, one task" description: "Combine CRM, finance, telephony and development data in a verifiable workflow." group: "Product" order: 30 --- ## Deployment addresses - Documentation: https://ctx4.me/docs.md - Agent index: https://ctx4.me/docs/agent-index.json - Console and connections: https://console.ctx4.me/integrations - MCP: https://ctx4.me/mcp - HTTP API: https://ctx4.me/v1 - Composio base URL: https://ctx4.me/compat/context4/v1 - OpenAPI: https://ctx4.me/docs/openapi.json - HTTP/MCP inventory: https://ctx4.me/docs/api-index.json - Composio routes: https://ctx4.me/docs/compat-routes.json - Connectors: https://ctx4.me/docs/connectors.json # Business workflows: two services, one task Your CRM knows whom you promised to call back. Telephony knows whether the conversation happened. A finance service knows which payments have been recorded. When AI receives data from two systems, it can prepare the next step using both sides. The external examples below are followed by four workflows to implement through Context4. These are agent setup instructions, not reports of completed Context4 deployments. We have not measured time savings or sales growth from them. ## What companies already do **WowSpeak online school: amoCRM + Wazzup.** In Wazzup's published case study, the school uses a customer's CRM status and return date for automated messages. Wazzup also sends questionnaires and lesson reminders. This illustrates combining sales data with a communication channel; the implementation uses the integration described in the case study. [WowSpeak case study by Wazzup](https://wazzup24.ru/blog/kejs-wowspeak/). **ActivSports: amoCRM + Wazzup24.** Integrator Aspire describes connecting Wazzup24 to amoCRM to communicate with customers on WhatsApp from the CRM. The source identifies a specific company and pair of systems. This project's results are not Context4 results. [Aspire implementation case study](https://startup.aspire.agency/work/2024-activsports-wazzup24-amocrm). Providers also document workflows for which we do not claim a specific customer: - MANGO OFFICE describes forwarding missed calls to Bitrix24 and tracking their handling. [Bitrix24 and MANGO OFFICE integration](https://developers.mango-office.ru/support/4_integratsii/1_vse-integratsii/16_bitrix24/3_obrabotka_zvonkov/04_1_4_kontrol_za_obrabotkoy_propuschennogo_zvonka/obzor/). - FinTablo documents importing CRM deals and mapping fields. This is a separate product, FinTablo Connector, not a Context4 feature. [FinTablo guide](https://help.fintablo.ru/article/30329). - Linear documents creating issues from Sentry errors and linking them. This is the providers' native integration. [Linear documentation](https://linear.app/docs/sentry). ## Before running a workflow Connect both services and check the tools available in your account. All connectors mentioned here are listed in the public Context4 catalog as **beta**. An action's presence in the catalog does not guarantee access through a particular connection. The sequences below specify **action keys**, such as `crm.lead.get`. These are not universal MCP tool names: the agent must choose the relevant connection, find the action and read its current input schema. The same key in different services identifies different tools. For recurring work, your agent or application needs a schedule or external trigger, mapping storage and a log of completed steps. The workflows below do not create those facilities. Store record IDs together with connection IDs: identical numbers in different accounts do not identify the same entity. Make changes, send messages and place calls only within an explicitly agreed task. If the user has not authorized a specific action or automation rule, show the read results and proposed changes before executing. Do not assume Context4 guarantees a separate confirmation dialog in every AI client. ## 1. Remind a customer of the next step: amoCRM + Wazzup **Business task.** A customer has reached an agreed deal stage, but the manager must separately find the phone number and a suitable message template. **Data from two systems.** amoCRM supplies the deal, linked contact and phone number. Wazzup supplies available channels, their state and templates with permitted channels. The agent chooses a message for the deal stage and checks that the selected channel can send it. ### Agent sequence 1. In amoCRM, run `crm.lead.get` for the selected deal. Retrieve the linked contact with `crm.contact.get`. If no contact ID is returned, use a previously verified mapping or ask for it; do not choose a person by name alone. 2. In Wazzup, run `messaging.channel.list` and `messaging.template.list`. Use the returned data to choose a working channel and suitable template, checking its status and channel list. 3. Map the contact's phone number to `chatId`. For this connector, `chatId` is an international phone number containing digits only; an amoCRM contact ID is not valid here. Store the mapping “amoCRM connection + contact ID → Wazzup connection + channelId + chatId”. 4. Prepare the text using deal fields. Show the recipient, channel, template and substituted values. After approval, run `messaging.message.send_template`: take `templateId` from the selected template's `templateGuid`, and values from the agreed data. 5. Store the returned `messageId` and operation state. `accepted` means the request was accepted, not that delivery or reading was confirmed. **Duplicate prevention.** Before sending, check the log key “connection + deal + stage/reason + template version”. Lock concurrent processing of that key. Do not treat `crmMessageId` as proof of guaranteed deduplication. If sending succeeds but saving the result fails, check the operation and Wazzup first; do not automatically resend when the outcome is unknown. **Expected result.** An approved message for the intended deal is sent through a checked channel without manually copying the number. The current Wazzup action set cannot read conversation history or delivery status: this workflow cannot establish that the customer has not replied for a long time or has read the message. Check channel rules and template availability separately. **Task for the agent:** “Prepare a Wazzup reminder for this amoCRM deal. Read the contact, channels and templates. Show the number, template and values; send after my approval. Stop if the previous send's outcome is unknown.” ## 2. Prepare payment follow-up: amoCRM + FinTablo **Business task.** The manager sees the sale amount in the CRM but needs to check recorded payments and obligations before a conversation. **Data from two systems.** amoCRM supplies the deal, contact and owner. FinTablo supplies the linked financial deal, obligations and transactions. The result is a set of payment questions linked to the sale's owner. ### Agent sequence 1. In amoCRM, run `crm.lead.get`, then `crm.company.get` or `crm.contact.get` for the linked party if its ID is known. 2. Find the verified mapping “amoCRM connection + deal ID → FinTablo connection + deal ID”, plus the counterparty mapping. During initial setup, read `deal.list` and `partner.list` in FinTablo and propose candidates to a person. Identical company names are insufficient; compare registration details where available and store confirmed IDs. 3. In FinTablo, call `deal.get`, `obligation.list` and `transaction.list` for the financial deal. Separate planned and actual transactions by `isPlan`, accounting for direction, currency, period and every response page. 4. Prepare a summary: CRM deal amount, financial deal data, unpaid obligations and actual receipts for the chosen period. Do not add obligations and transactions as independent debts: they may refer to the same payment. Flag amount differences for reconciliation; do not correct them automatically. 5. In amoCRM, check `crm.task.list`. After approval, use `crm.task.create` to assign the owner a task to check a specific discrepancy or contact the customer. Agree the deadline and task type; verify the result using `crm.task.get`. **Duplicate prevention.** Use the log key “CRM deal + financial deal + reconciliation period + task type”. Store the created task ID; before retrying, read that task and the task list. If reading FinTablo stops partway through pagination, finish reading before drawing conclusions. If task creation succeeds but the response is lost, find the task before deciding whether to retry. **Expected result.** The manager receives conversation preparation based on two systems and a concrete task. This is not a real-time bank statement or proof of an overdue payment: import freshness, contract terms, refunds, taxes and currency differences need separate consideration. The workflow does not alter financial records or declare a sale paid merely because amounts match. **Task for the agent:** “Reconcile this amoCRM deal with the confirmed FinTablo deal for the specified period. Separate planned payments from actual payments. Show discrepancies and suggest a task for the manager without changing financial records.” ## 3. Follow up a missed call: Bitrix24 + MANGO OFFICE **Business task.** Telephony contains a missed call, and the supervisor needs to know which existing customers have no next step. **Data from two systems.** MANGO OFFICE returns call records, numbers and answer times. Bitrix24 supplies the contact, deals, owner and existing tasks. The agent checks the call in the context of customer work. ### Agent sequence 1. In MANGO OFFICE, run `telephony.history.request` for an agreed period of at most 28 days. Save the `key`. Retrieve the report through `telephony.history.result`, respecting `pollAfterMs`; `pending` does not mean there were no calls. 2. Identify unanswered inbound calls in the completed report according to the provider's field rules. Do not treat every termination code as a missed call; account for subsequent answered calls from the same customer within the period. Store `entry_id` and the numbers. 3. In Bitrix24, find the contact through `crm.contact.list`, then read `crm.contact.get` and linked deals through `crm.deal.list` / `crm.deal.get`. Match the normalized external number, then store the contact ID. If a number is shared or multiple contacts match, ask a person to choose. 4. Use `task.task.list` to check whether a task already exists for this call. Show the contact, deal, call time, owner and proposed deadline. After approval, run `task.task.create`, including a customer link and the call's `entry_id` in the description. 5. Verify the task with `task.task.get` and save its ID. If the user has separately authorized an actual call, first read `telephony.employee.list` and agree the employee and `extension`, then use `telephony.call.callback` with the exact customer number and `command_id`. **Duplicate prevention.** For a task, use the key “MANGO connection + entry_id + next-step type”. Keep a separate attempt record for a call: an accepted request must not be automatically repeated like a read. If the response is lost, check the operation and telephony. If the report expires (`absent-or-expired`), request the same period again and exclude processed `entry_id` values. **Expected result.** Known missed inquiries receive a verifiable next step and an owner. A created task does not mean the customer was called back; `submitted` for a callback means the command was sent, not that a conversation occurred. Check report completeness: a limited response does not establish that there were no other calls. An existing native integration may create tasks independently; account for it to avoid duplicate work. **Task for the agent:** “Match MANGO OFFICE missed inbound calls in this period to Bitrix24 contacts, deals and tasks. Show inquiries without a next step. Do not create tasks or place calls until the list is approved.” ## 4. Assign an error without duplicates: Sentry + Linear **Business task.** An error is visible in monitoring, but before creating an issue you need to find out whether the development team is already handling it. **Data from two systems.** Sentry supplies the error ID, events, frequency and failure context within its response. Linear supplies existing issues, their state, team and discussion. The agent combines technical error evidence with current work plans. ### Agent sequence 1. In Sentry, run `issue.triage_pack` for the selected error. Save the organization, project, numeric ID and issue URL. Do not copy secrets or unnecessary event personal data into the issue. 2. In Linear, run `issue.search` using the saved Sentry ID/URL and key error characteristics. Use `issue.overview` for candidates to read issues and comments. Matching titles alone do not confirm a shared cause. 3. If a mapping is already confirmed, show an update for the existing issue. After approval, add it with `comment.create`. If no issue exists, run `team.list`, agree the team and content, then call `issue.create`. 4. Include the Sentry URL, observed facts and observation period in the description or comment. Separate facts from hypotheses. Store the mapping “Sentry organization + error ID → Linear workspace + issue ID”. 5. Verify the result through `issue.get` or `comment.list` in Linear. Show the user the URL of the created or updated issue. **Duplicate prevention.** Before writing, lock the log key “Sentry organization + error ID + Linear team”. For comments, add the period or last processed event ID. If creation succeeds but updating the log fails, search by the Sentry URL first. Do not automatically create a second issue when the outcome is unknown. **Expected result.** The team receives an issue with context from a real failure or an update to an existing issue. Adding a text link does not enable the native two-way Linear–Sentry integration. These steps do not promise automatic Sentry closure when Linear work completes and do not establish a root cause without further investigation. **Task for the agent:** “Read this Sentry error and find its linked Linear issue. Show what both systems already know. Suggest a comment or a new issue, separate facts from hypotheses and wait for approval before writing.” ## How to verify the first run Start with one known record. Check that the agent read data from **both** services, showed the matching method and reported ambiguities. After an authorized write, open the result in the original service. A repeated run should find the completed step; a failure in the second service should leave a clear state for resuming. Next, read about [connecting services](https://ctx4.me/docs/connections.md), [actions and results](https://ctx4.me/docs/actions.md) and [working through AI and MCP](https://ctx4.me/docs/ai-mcp.md).