Persat

Connect AI agents to Persat, a field service management platform used across Latin America. Agents dispatch work orders, track technicians and devices, create and track deliveries, and read the digital forms a technician submitted, moving them through their workflow states.

34 actions API key available

Platform Documentation ↗

A scheduled poll of List Clients with the Updated After filter picks up records changed in the ERP since the last run

List Client Custom Fields returns the custom field IDs this account requires before any payload is built

Each incoming record is checked for latitude and longitude, because Persat never geocodes and stores coordinates exactly as sent

Update Client patches the matched records and Create Client adds the genuinely new ones

Records that resolve to two Persat clients are collected as candidate duplicates rather than merged

The service manager receives the duplicate set with the work order and form history attached to each side

A person chooses which client survives before Delete Client is allowed to run on the other

What This Integration Enables

Persat is a field service platform built for Latin American service operations, and the thing it actually governs is the day of a technician who is not sitting at a desk. Work orders, deliveries, routes, digital forms and GPS positions are all one object model, which is why a dispatcher can look at a screen and know both what is scheduled and where the van is. This connector opens that model to agents so the scheduling side of the business stops depending on someone retyping a ticket. Clients are fully writable through List Clients, Get Client, Create Client, Update Client and Delete Client, with List Client Custom Fields exposing the per account fields that carry the data the vendor never shipped. Work orders move through their real lifecycle with Create Work Order, Move Work Order To Pending, Cancel Work Order and Close Work Order, and Get Work Order Tracking Link and Get Work Order PDF produce the artefacts a customer and an auditor each want. Deliveries have their own path through Create Delivery, Get Delivery Tracking Link and Get Delivery PDF. Digital forms are read, not written: List Digital Forms, Get Digital Form and Get Digital Form PDF pull back what the technician submitted in the field, and Update Digital Form State advances that submission through the workflow states the account has configured. The tracking group, Get Last GPS Position, Get Tracking Statistics and Get Client Visits, is how a supervisor turns a day of driving into a number.

Several behaviours decide whether a flow built on this is correct rather than merely working. Persat never geocodes over the API, in either direction: latitude and longitude are stored exactly as sent, the address is never derived from the coordinates, and omitting coordinates on a client places it at 0,0. Client custom fields are keyed by custom field ID and every value is sent, stored and returned as a string with no type validation, so the connector is honest about what it is passing through rather than pretending the platform will catch a bad value. Cancel Work Order and Close Work Order are state transitions with preconditions, and a work order in the wrong state returns a conflict instead of moving, which is the correct behaviour and worth designing around. On both of those transitions the Label IDs you send overwrite the work order's existing labels rather than adding to them, so omitting the field keeps the labels and sending an empty array clears them. Tracking statistics and client visits are computed overnight, so a query against today returns null and only past days are meaningful. Pagination is not uniform: List Clients and List Digital Forms use offset and limit, List Deliveries uses a cursor and ends when the next cursor is null rather than when a total is reached, and List Work Orders requires a from and to date across a window no longer than 15 days.

On events, be precise. This connector ships no triggers. Persat does have webhooks, but they are configured only inside the Persat panel under Integraciones y Partners, then Administrar webhooks, and there is no API to create or manage a subscription, so nothing here registers one and nothing here creates a FlowRunner trigger. An account can point a Persat webhook at a callback endpoint of your choosing, which is a configuration made in Persat rather than a capability of this connector. Change detection is a scheduled poll: List Clients on Updated After, List Work Orders over a rolling window of at most 15 days filtered by state, List Digital Forms over a date range, List Deliveries paged forward by cursor, and Get Last GPS Position per device.

Without FlowRunner

Two systems, two client registers The ERP and the dispatch board disagree about addresses, and the technician trusts whichever screen is open

Coordinates arrive by accident A client is created without latitude and longitude and nobody notices until a van is routed to the wrong place

Cleanup is done by hand and rarely Duplicate clients accumulate because deleting one means reading its whole service history first

With FlowRunner

One reconciled register Incremental sync runs on the Updated After cursor instead of a full reload of every client

Coordinates are a precondition A missing coordinate stops the write instead of quietly placing the site at 0,0

Cleanup with the history in view Every proposed deletion is presented with the work orders and forms it would take with it

Use Case Scenarios

One client register across the ERP and the dispatch board

A service company keeps customer master data in Acumatica and dispatches from Persat. On a schedule the agent reads the ERP for accounts modified since the last run, then calls List Clients with Updated After to pull the Persat side of the same window rather than reloading the entire register. It reads List Client Custom Fields first, because the custom field payload is keyed by ID and those IDs belong to the account, not to the documentation. Matched records go through Update Client. Genuinely new sites go through Create Client, but only when latitude and longitude are present, since Persat stores what it is given and a client created without coordinates sits at 0,0 forever. Anything that resolves to two Persat clients is set aside as an automation exception instead of being merged, because merging here is a deletion.

A maintenance request that becomes a scheduled visit

A tenant or a customer raises a fault in a ticketing system. The agent resolves the site with List Clients, calls Create Work Order against it with the problem description and the scheduling window, and then calls Get Work Order Tracking Link so the requester gets a link they can watch rather than a promise that someone will call. The dispatch channel in Slack receives the work order reference, the client, and the link. As the job progresses the agent uses Move Work Order To Pending, Cancel Work Order or Close Work Order depending on what actually happened, and because those transitions have state preconditions a conflict response is reported as a state problem rather than retried into a loop. When the job closes, Get Work Order PDF stores the signed document in FlowRunner file storage and the reference goes back onto the originating ticket.

Proof of service that reaches the systems that need it

Field technicians complete inspections and proof of delivery on digital forms in the Persat app. On a schedule the agent calls List Digital Forms over the previous day's range, reads each submission with Get Digital Form, and writes the values into a completed jobs sheet in Google Sheets alongside the client and the work order. Get Digital Form PDF stores the rendered document so the archived copy is the one the customer signed, not a reconstruction. Where a submission is complete and passes the account's own checks, Update Digital Form State advances it to the next configured state, resolved from List Digital Form States rather than from a state name written into the flow months ago. Where a form comes back with a failed check, the agent leaves the state alone and raises it to the supervisor, because a form that advances is a form nobody looks at again.

Human-in-Loop Highlight

Delete Client is the operation to gate, and the reason is written plainly in the vendor's own documentation: it permanently removes the client and its entire history, including all forms and work orders performed on it, and it cannot be undone. That is a much larger blast radius than the word "client" suggests. In a field service business the record of who visited that site, what state the machine was in, and which checklist the technician signed is the evidence that gets produced when a warranty claim, a service level dispute or a safety question comes up two years later. A duplicate merge is a routine data quality task everywhere else. Here it destroys the service file. So the agent does the part it is good at and stops before the part it is not. It resolves the duplicate set, then calls List Work Orders and List Digital Forms against both sides so the human is looking at consequences rather than at two rows. It posts to the service manager: "The ERP sync matched 6 accounts to two Persat clients each. On 4 of them one side has no work orders and no forms and I can delete it safely if you agree. The other 2 have history on both sides. Client 41288 Frigorifico del Sur has 31 work orders and 22 signed digital forms going back to 2023, and client 60915 with the same tax ID has 4 work orders from the last two months and the correct new address. Deleting either one takes its forms and work orders with it permanently. Which record survives, and do you want the other one left in place instead of deleted?" The manager answers once, and the agent applies the decision. This is the human-in-the-loop moment on a platform where the destructive operation is cheap to call and impossible to reverse, and it is the shape Orchestration as a Service is built around: the agent assembles the evidence, and a person holds the one decision that cannot be taken back.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

34 actions

Clients

List Clients Returns clients with offset and limit paging, a maximum limit of 100, and an Updated After filter that makes incremental sync possible without reloading the register. This is the read that stands in for the events this connector does not receive.
Get Client Returns a single client in full, used to confirm what a record actually holds before an update or a deletion is proposed.
Create Client Creates a client. Coordinates are stored exactly as sent and are never derived from the address, so a client created without latitude and longitude is placed at 0,0.
Update Client Updates an existing client, including its custom fields. Required custom fields cannot be set to an empty string on update.
Delete Client Permanently removes the client and its entire history, including all forms and work orders performed on it. This cannot be undone, which is why it runs behind an approval rather than inside a sync.
List Client Custom Fields Returns the custom field IDs configured for clients on this account, along with which are required. Custom field payloads are keyed by ID, so this read runs before any client write is assembled.

Work Orders

List Work Orders Returns work orders across a from and to date range that cannot exceed 15 days, searched by whole days regardless of time zone. Repeating and future work orders may return an ID of -1 or unset and are identified by their rule and instance fields instead.
Get Work Order Returns a single work order in full, used to confirm state before a transition is attempted.
Create Work Order Schedules a job against a client. This is the write that turns an inbound ticket, order or maintenance request into something a technician will actually see.
Cancel Work Order Cancels a work order that is in PENDIENTE, PROYECTADA or ASIGNADA. Any other state returns a conflict, which is reported as a state problem rather than retried.
Close Work Order Closes a work order that is in INFORME, CERRADA_OK, CERRADA_CON_DESVIO or CERRADA_NO_CUMPLIDA. As with cancel, the Label IDs you send overwrite the existing labels rather than adding to them, so omit the field to keep them and send an empty array to clear them.
Move Work Order To Pending Returns a work order to the pending state, used when a scheduled visit falls through and the job needs to go back into the queue.
Get Work Order Tracking Link Returns a public tracking link for a work order, so the requester can follow the visit instead of calling to ask about it.
Get Work Order PDF Downloads the work order document and stores it in FlowRunner file storage, returning the stored file metadata with a public URL.

Deliveries

List Deliveries Returns deliveries using cursor pagination rather than offsets. The list ends when the next cursor is null, so the total must not be used to detect the end.
Get Delivery Returns a single delivery in full.
Create Delivery Creates a delivery for dispatch, typically from an order management system.
Delete Delivery Permanently removes a delivery.
Get Delivery Tracking Link Returns a public tracking link for a delivery, which is the artefact worth sending to the recipient the moment the delivery is created.
Get Delivery PDF Downloads the delivery document and stores it in FlowRunner file storage.
List Delivery Routes Returns the delivery routes configured on the account, used to place a delivery on the right run.

Digital Forms

List Digital Forms Returns submitted digital forms over a date range with offset and limit paging, optionally filtered by client or form type. This is the polling read for proof of service.
Get Digital Form Returns a single submitted form with its values, so the answers a technician gave in the field can drive a downstream decision.
Update Digital Form State Advances a submitted form to another configured workflow state. The form content itself is not writable through this connector.
List Digital Form States Returns the workflow states this account has configured, so a state is set by a resolved value rather than by a name carried in from elsewhere.
Get Digital Form PDF Downloads the rendered form and stores it in FlowRunner file storage, which is how the archived copy stays the one that was signed.

Follow Ups

Create Follow Up Attaches a follow up reminder to a client so a technician or supervisor is prompted at the right time rather than relying on someone's calendar.

Devices and Users

List Devices Returns the field devices registered on the account.
Get Device Returns a single device, used before a GPS position is requested against it.
List Users Returns the users on the account.
List Active Technicians Returns the technicians currently active, which is the read that tells a scheduling flow who is genuinely available rather than who exists.

Tracking

Get Last GPS Position Returns the last known position for a device. Timestamps are expressed in UTC but should be read as the account's local time.
Get Tracking Statistics Returns computed tracking statistics for a past date range. Statistics are computed overnight, so a query against today returns null.
Get Client Visits Returns the visits recorded against clients for a past date range, used to build field productivity reporting without asking anyone to fill in a timesheet.

Frequently Asked Questions

What can FlowRunner do with Persat?

FlowRunner agents can run List Clients, Get Client, and Create Client in Persat, plus 31 more actions.

Does connecting Persat to FlowRunner require OAuth?

No. Persat connects to FlowRunner with an API key, no OAuth flow required.

Can Persat trigger a FlowRunner workflow automatically?

Persat doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Persat

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us