# Runs and refusals

> What each run of a push did, why a record was refused or held, how Push treats your Salesforce API allowance, and what happens when runs fail.

Open a push under **Activate · Push** to see its runs. **Runs** lists the last thirty, newest first. Each says in a sentence what it did, such as "Sent 31 records. Salesforce accepted every one.", with how it started, when, and how long it took. Open a run to see how many Salesforce API calls it used and the records it couldn't deliver.

## What a run's status means

| Status | What it means |
|---|---|
| **succeeded** | Everything that changed arrived. A run that found nothing changed succeeds without calling Salesforce. |
| **partial** | It sent, but Salesforce refused some records, or some rows couldn't be sent as they stood. |
| **skipped** | It sent nothing, for a reason that is nobody's fault: the workspace is paused for its budget, the org needs connecting again, the push was paused after the run was queued, or your org's API allowance was too low. It doesn't count as a failure. |
| **failed** | It couldn't finish. The reason is one sentence, and it counts toward the push pausing itself. |
| **cancelled** | It was cut off before it finished. What Salesforce didn't confirm is sent on the next run. |
| **queued**, **running**, **waiting** | Under way. **waiting** is a bulk job Salesforce is still working through. The page updates itself until the run ends. |

## How changes are sent

Up to 2,000 changed records go in requests of up to 200, and each record's answer is recorded as it comes back. More than that go as one bulk job, which Salesforce works through in its own time while the run shows **waiting**. Either way, a value counts as sent only once Salesforce accepts it.

## Records it couldn't deliver

There are two kinds, and an open run lists both with the record each was for.

- **Rows sanda couldn't send as they stand.** A value that doesn't fit its field (text longer than the field holds, a word in a checkbox, a day that doesn't exist), a value that isn't an Id of the object, or several rows that match one record. These never reach Salesforce.
- **Records Salesforce refused.** Salesforce's own message comes first, because it names your validation rule or field. sanda adds a hint for the common refusals, such as a field the Salesforce user can't edit or a record that has been deleted.

A run keeps up to 200 of them, which is enough to see the pattern. Its counts say how many there were in all.

The preview lists the first kind before anything is sent. See [preview and run](https://docs.sanda-os.com.au/push/create-a-push#preview-and-run).

## Held records

A record Salesforce refuses 3 runs in a row, for the same value, is held: sanda stops sending it until its value changes. A validation rule that refuses a number refuses it on every run, and sending it again spends your API allowance to learn nothing new. A changed value is a new question, so it is sent.

A refusal about the moment rather than the value, such as Salesforce saving the same record for someone else at that instant, doesn't count toward holding a record. It is sent again on the next run.

## Send everything again

**Send everything again** sends every record the push reads, including the ones Salesforce already has, and releases held records. Use it when values in Salesforce were changed by hand and you want sanda's back, or once you have fixed whatever made Salesforce refuse a record. It costs about one API call for every 200 records.

## Your Salesforce API allowance

Your org's daily API allowance is shared with every other integration and with your own users, so Push is careful with it.

- **A run with nothing to send makes no call at all.** Not even to sign in.
- **A run with something to send reads the allowance first.** If sending would leave less than 10% of it, and never less than 500 calls, the run sends nothing, says how many calls were left, and is skipped. The next run carries on.
- **Most runs are cheap.** One call to read the allowance, then one for every 200 changed records. A bulk job costs a handful of calls whatever its size.

Each org under **Salesforce orgs** on the Push page shows how much of the allowance was used at the last reading.

## When runs fail

A failed run emails owners and admins, at most once a day for each push, when **When a scheduled run fails, or pauses itself after failing repeatedly** is ticked under **Settings · Plan & budget · Budget & alerts**. See [budgets and alerts](https://docs.sanda-os.com.au/billing/budgets-and-limits).

After as many failed runs in a row as its **Pause itself after** says, a push pauses itself and is marked **suspended**. Fix the cause, then press **Resume**. A skipped run never counts, and neither does a failure caused by the org needing to be connected again.

## Pause, resume and delete

- **Pause** stops the push's schedule and its runs after a sync. **Run now** still works.
- **Resume** turns it back on, starts its schedule from now rather than catching up on what it missed, and forgets the failures that paused it.
- **Delete push**, at the foot of the page, removes it. Nothing changes in Salesforce: the values it wrote stay where they are.

## If your edition changes

A workspace keeps every push when it moves to an edition with fewer. The oldest keep running, up to the new edition's count. The others keep their definitions, show **not running**, and say why. On Basic, none runs and the page shows what the next edition adds. Moving back up is immediate. See [editions](https://docs.sanda-os.com.au/billing/editions).