> For the complete documentation index, see [llms.txt](https://docs.flowretail.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flowretail.com/docs/day-to-day-operations/selling/adding-a-customer-to-an-order.md).

# Adding a customer to an order

What changes when a customer goes on or comes off an order — and which prices survive it.

Adding a customer is not just recording who is buying. It **re-prices the order**, because the customer may have their own agreed prices or be eligible for customer-specific campaigns.

Removing a customer re-prices it again, the other way.

## What happens on the order

When a customer is added or removed, Flow Retail walks every line and looks the price up again for that customer. Then it re-applies campaigns across the whole order.

Three rules govern what actually changes:

| Line                                                             | What happens                                               |
| ---------------------------------------------------------------- | ---------------------------------------------------------- |
| Price was set **manually**                                       | **Left alone.** A manual price survives the recalculation. |
| No price found for the customer, or the price comes back as zero | **Left alone.** The existing price stands.                 |
| Anything else                                                    | Re-priced to the customer's price                          |

The first rule is the one worth knowing. A price someone typed in by hand is treated as a deliberate decision and is **not** overwritten when the customer changes.

## Where a price came from

Every line records the origin of its price, which is how you tell why a line costs what it does:

| Origin     | Meaning                                     |
| ---------- | ------------------------------------------- |
| `MANUAL`   | Typed in on the order. Survives re-pricing. |
| `CUSTOMER` | From the customer's own agreed price        |
| `CAMPAIGN` | A campaign matched                          |
| `STORE`    | The store's price                           |
| `TENANT`   | The chain-wide price                        |
| `PRODUCT`  | The product's own price                     |
| `EXTERNAL` | Supplied by an external system              |

If a line did not change when you expected it to, check whether its origin is `MANUAL`.

## Add the customer early

Because adding a customer re-prices the order, do it **before** discussing price with them, not after. Adding the customer at the end can move prices that have already been quoted — and removing a customer can move them back.

Manual prices are the exception, and that is also the workaround: if a price has been agreed and must not move, set it manually.

## What this means for you

* **Add the customer first**, then talk about price.
* **A manual price is a commitment.** It will not be recalculated, which is usually what you want, but it also means it will not pick up a better customer price later.
* **Campaigns are re-applied after re-pricing**, so a customer becoming eligible for a campaign is handled in the same pass — see [Discounts on an order](/docs/day-to-day-operations/selling/discounts-on-an-order.md).

***

*Last updated 19.09.2026*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.flowretail.com/docs/day-to-day-operations/selling/adding-a-customer-to-an-order.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.