> For the complete documentation index, see [llms.txt](https://doc.wearepatchworks.com/product-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.wearepatchworks.com/product-documentation/company-management/company-insights/company-insights-overview/about-operations.md). # About operations ## Introduction In Patchworks, an `operation` is counted whenever a request is made to send or receive a payload to/from an endpoint or query. Crucially, we're not concerned with the number of items in the payload - we simply count the number of times a process flow requests to send or receive a payload. This might happen in several ways:

Mechanism	Summary
Connector shape	A request is made (successfully or otherwise) to receive data from a specified endpoint/query.
Connector shape	A request is made (successfully or otherwise) to send data to a specified endpoint/query.
Webhook trigger	A `webhook` is received (with or without a payload) in the first step of the process flow.
Event trigger	An `event` is received (with or without a payload) in the first step of the process flow.
Patchworks API call	A `Patchworks API call` is received (with or without a payload) in the first step of the process flow.

## Considerations for your operations count The number of payloads that a process flow sends or receives correlates with the number of operations logged. In the most straightforward case, you might create a process flow that always *receives* a single, unpaginated payload from one system and then *sends* a single, unpaginated payload to another system - this would be an operations count of 2. However, as the complexity of a process flow increases, so too does the potential for an increase in the number of payloads being processed. The most likely ways that this can happen are: **Paginated data.** If you receive paginated data, you receive 1 payload for each page of data - so each page represents 1 *receive* operation. In short, an initial data pull can result in multiple *receive* operations. And if you receive multiple pages, it follows that multiple pages continue through the flow - which means (potentially) multiple pages will be sent into your destination system, resulting in multiple *send* operations. **Flow control.** The [flow control](/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/flow-control-shape.md) shape is typically used to batch an incoming payload into multiple, smaller payloads for onward processing. So, even if you start by *receiving* 1 payload, it's likely that you will be *sending* multiple payloads at the end of the flow. {% hint style="info" %} Retries for failed connection requests are included in your operations count. For more information on connector retry settings, please see [Understanding how data flows through shapes (retries)](/product-documentation/process-flows/building-process-flows/understanding-how-data-flows-through-shapes.md#retries). {% endhint %} ### Examples The examples below show the impact that these scenarios can have on operation counts:


In the simplest of flows you might receive 1 payload from a source endpoint which contains 350 records in a single, unpaginated payload. The flow goes on to send that payload to a destination endpoint. This results in 2 operations - 1 for the receive operation and 1 for the send operation.			tile 1a.png
In a slightly more complex flow you might receive 1 payload from a source endpoint which contains 350 records in a single, unpaginated payload. The flow continues with a flow control shape which batches this data into smaller chunks, resulting in 5 payloads, each containing 70 records. The flow goes on to send all of these payloads to a destination endpoint. This results in 6 operations - one for the receive operation and 5 for the send operations.			tile 2a.png
In this example, our incoming data is paginated as 50 records per page, so we receive 350 records as 7 payloads (50 records in each). The flow proceeds to send all of these payloads to a destination endpoint. This results 14 operations - 7 for receive operations and 7 for send operations.			tile 3a.png
In this example, our incoming data is paginated as 50 records per page, so we receive 350 records as 7 payloads (50 records in each). The flow continues with a flow control shape which batches this data into single-item payloads. The flow goes on to send all of these payloads to a destination endpoint. This results 357 operations - 7 for receive operations and 350 for send operations.			tile 4a.png