Uspacy
CRMConnect AI agents to Uspacy, a Ukrainian CRM and collaboration workspace. Agents create and update CRM entities, assign tasks, and read the company structure behind each record.
What This Integration Enables
Uspacy is a Ukrainian CRM and collaboration workspace, and this connector reflects a product where the CRM and the day-to-day work of the team live in the same place. Leads, deals, contacts, and companies share the same entity route family, so one set of actions addresses all four: List CRM Items, Create CRM Item, Update CRM Item, and Move CRM Item to Stage work against whichever entity you name. Tasks are a first-class object alongside them, with their own stages, statuses, and priorities, and Search runs across services rather than within one. That shape suits a flow that has to touch a record and the human work attached to it in the same pass, which is most flows worth building.
Three things determine whether an agent behaves well here. First, discover before you write. Create CRM Item accepts common fields directly and merges a Fields object for everything else, keyed by field codes rather than by the labels shown on screen, so Get CRM Fields is the action that turns a label into something a payload can actually use, and Get CRM List Values resolves the permitted values behind a dropdown. Get CRM Funnels and Get CRM Funnel Stages do the same job for pipelines, because a stage is referenced by its identity and not by its name. Second, know what this connector does not carry. Item-level get by ID, item-level delete, and mass edit for CRM entities are not exposed by the vendor's public reference and were left out rather than invented, so a flow reads a single item by filtering List CRM Items and it cannot remove one at all. Tasks are different: Get Task, Update Task, Complete Task, and Delete Task all exist, and Delete Task is permanent. Third, understand the identity the agent borrows. Each customer runs on a per portal host of the form https://{domain}.uspacy.{tld}, with the region deciding the top level domain across Ukraine, the European Union, Brazil, and International, and authentication is a login exchange rather than a static key: the configured account email and password are posted to the sign in endpoint and exchanged for a short-lived Bearer JWT, cached for the flow run and re-minted automatically on expiry. That means every write an agent performs is attributed inside the portal to the person whose credentials are in configuration. Deadlines are Unix timestamps in seconds rather than milliseconds. Task status maps friendly labels onto notScheduled, scheduled, inWork, stopped, inControl, and ready, and priority onto low, notHigh, neutral, high, and veryHigh. Complete Task sets a status that depends on whether the acting account is the responsible user or the setter, matching the vendor's own behaviour. This connector ships no triggers, so change detection is a scheduled List CRM Items read using page and list paging with extra vendor filters passed through the Filters input.
Without FlowRunner
With FlowRunner
Use Case Scenarios
An inbound enquiry that lands in the right funnel with the right field codes
A website form or a chat conversation produces a prospect. The agent calls Get CRM Funnels and Get CRM Funnel Stages to resolve the funnel and its opening stage, then Get CRM Fields for the target entity so the payload is built against real field codes rather than the labels a form designer chose. List CRM Items with a filter on the email or company name checks whether this prospect is already in the pipeline, which matters more here than in most CRMs because there is no item-level delete to clean up a duplicate afterwards. Create CRM Item then writes the lead or deal with its common fields set directly and the rest merged through the Fields object, and Create Task attaches the first follow-up with a deadline expressed as a Unix timestamp in seconds and a priority mapped from the friendly label to its wire value.
Telephony activity written against the record it belongs to
A call completes in a phone platform. The agent runs Search to locate the matching CRM record across entities rather than guessing which one holds the number, then calls Log CRM Call to write the call event against it. Where the conversation produced a commitment, Create Task schedules the next step against the responsible user with the agreed deadline. Where it closed something out, Complete Task marks the existing task done, and it is worth knowing that the resulting status depends on whether the configured account is the responsible user or the setter of that task, so the completion a flow records may read differently from the one a rep would have recorded by hand. A summary posts to Slack for the account owner.
A funnel review that reads without moving anything
On a schedule the agent calls List CRM Items for deals with page and list paging and any vendor filters passed through the Filters input, then Get CRM Funnel Stages so stage identities can be reported as names a person recognises. For each item it reads the tasks attached through List Tasks and the owner through List Users and List Departments, which turns a pipeline listing into something more useful: a view of which deals have a named owner in a real department with a dated task against them, and which are simply sitting in a stage. The result appends to Google Sheets and a per-department summary goes to the sales manager. Nothing in this run writes, and the items it flags feed the gate below rather than being advanced automatically.
Human-in-Loop Highlight
Move CRM Item to Stage is the operation to gate here, and the reason is not that the write is large. It is that the write is signed. Uspacy authenticates by posting the configured account email and password to the sign in endpoint and exchanging them for a short-lived Bearer JWT, so the agent is not acting as an integration user with its own identity in the portal. It is acting as whichever employee's credentials sit in configuration. Every stage change, every task assignment, every field update appears in the portal, in the activity trail, and to every colleague looking at the record, as something that person did. Then consider what a stage move actually sets off. Stages in Uspacy are where a team hangs its own process, so moving a deal into a closing stage is not a label change, it is the event the portal's own automations and the people watching that funnel respond to. And this connector cannot walk it back cleanly: there is no item-level get by ID and no item-level delete for CRM entities here, so the agent reads a single item by filtering a list and cannot remove a record it should not have created. The realistic failure is a batch. An upstream system reports twelve deals as signed, the agent moves all twelve into the closing stage, and three of them were flagged by a data sync that ran before a correction landed. The finance lead sees three closures under a colleague's name, that colleague has no idea why, and the record shows no distinction between the nine that were right and the three that were not. So the agent stops before the move. It reads List CRM Items for the affected deals, resolves the target stage through Get CRM Funnel Stages, and posts to the funnel owner: "12 deals match a signed agreement upstream and are ready to move into the closing stage of the Sales funnel. 9 have a matching amount and a completed task recording the final call. 3 do not: two have no task activity in the last three weeks, and one shows an amount that changed in the source after the signature event. These writes are recorded in Uspacy under the account in configuration, so they will appear as your colleague's actions, and any portal automation on this stage fires immediately. Move the 9, move all 12, or hold the 3?" The owner answers once, and Move CRM Item to Stage runs only against the deals a person named. This is the human-in-the-loop moment on a CRM where the agent borrows a real person's identity to work, because an agent can assemble the evidence for every deal in the batch and only a person can accept having their own name on the result.
Agent Capabilities
21 actionsCRM entities
9- List CRM Items Returns items for a named entity across leads, deals, contacts, and companies, with `page` and `list` page-size paging and vendor filters passed through the Filters input. This is the scheduled read that substitutes for the events this connector does not receive, and the way a single item is located, since no item-level get by ID is exposed.
- Create CRM Item Creates a lead, deal, contact, or company. Common fields are accepted directly and everything else is merged through the Fields object, keyed by field codes rather than screen labels.
- Update CRM Item Updates an existing item's fields, using the same field code model as create.
- Move CRM Item to Stage Moves an item between kanban stages in its funnel. Stage moves are what the portal's own process and the people watching the funnel respond to, and they are recorded under the account in configuration.
- Get CRM Funnels Returns the funnels defined in the portal, resolved before any stage is referenced.
- Get CRM Funnel Stages Returns the stages within a funnel with their identities, so a move targets a real stage rather than a name.
- Get CRM Fields Returns the exact field codes an entity accepts, including custom fields. The discovery action that has to run before a create or update writes anything it cares about.
- Get CRM List Values Returns the permitted values behind a list field, so a dropdown value is written as the wire value rather than as its label.
- Log CRM Call Writes a telephony call event against a CRM record, closing the gap between the phone system and the customer history.
Tasks
7- List Tasks Returns tasks with paging, used to see what work is actually scheduled against a record or a person.
- Get Task Retrieves a single task with its status, priority, and deadline.
- Create Task Creates a task with a responsible user and a deadline expressed as a Unix timestamp in seconds. Priority maps friendly labels onto `low`, `notHigh`, `neutral`, `high`, and `veryHigh`.
- Update Task Updates a task, including its status, priority, deadline, and responsible user. Status maps onto `notScheduled`, `scheduled`, `inWork`, `stopped`, `inControl`, and `ready`.
- Complete Task Completes a task. The resulting status depends on whether the acting account is the responsible user or the setter, matching the vendor's own behaviour.
- Delete Task Permanently removes a task and cannot be undone.
- Get Task Stages Returns the stages tasks move through, used to report progress in terms the team recognises.
People and structure
4- List Users Returns the portal's users, used to resolve a responsible person before work is assigned.
- Get User Retrieves a single user.
- Get Current User Returns the account the configured credentials sign in as. Worth calling once in a flow, since this is the identity every write will be attributed to.
- List Departments Returns the company structure behind the users, which turns a per-owner report into a per-team one.
Search
1- Search Runs a cross-service search across the portal rather than within a single entity, used to locate the record a phone number, email, or company name belongs to before writing against it.
Frequently Asked Questions
What can FlowRunner do with Uspacy?
FlowRunner agents can run List CRM Items, Create CRM Item, and Update CRM Item in Uspacy, plus 18 more actions.
Does connecting Uspacy to FlowRunner require OAuth?
No. Uspacy connects to FlowRunner with session-based authentication, no OAuth flow required.
Can Uspacy trigger a FlowRunner workflow automatically?
Uspacy doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Uspacy
$100 in credits. No card required. Connect in minutes.