# Supplier workflow interview exercise

This original Python exercise accompanies the Salesforce interview guide. It demonstrates a **proposed integration pattern**, not Salesforce or Agentforce Operations internals. It makes no network calls and uses synthetic data. Python's standard library is sufficient.

Run the five-scenario demonstration:

```bash
python3 labs/supplier_workflow.py
```

Run the behavior tests:

```bash
python3 -m unittest discover -s labs -v
```

The default demo uses fresh temporary databases. With `--directory /tmp/my-salesforce-lab`, data survives between runs; repeated runs can start from completed operations.

Explain these observations in an interview:

1. The mock ERP commits, but its response is lost. The workflow records `RECONCILING`.
2. After a client restart, reconciliation finds the existing receipt and confirms completion. There is still one business effect.
3. A synthetic bank-detail change waits for approval. Approval binds the exact proposal fingerprint and expires.
4. A repeat of the same request produces no second effect. Reusing its key for different values fails.
5. Identity comes from trusted fixtures; it is not accepted from a model's output. The tool contract rejects unauthorized suppliers, unsupported fields and invalid evidence.

The durable uniqueness guarantee is implemented in the **mock target**. This is a deliberate premise, not something an orchestrator can grant to an arbitrary ERP. Discuss what you would do if a real ERP has neither idempotency keys nor a reliable lookup: constrain retries, reconcile by business reference where possible, and route uncertain outcomes to an operator.

Simplifications to discuss: a local single-process teaching setup; no real identity provider, encryption, secret management, ERP authorization layer, document extractor, model, Salesforce connection, worker lease, distributed queue, full schema/financial validation, multiregion recovery or production monitoring. Approval is checked immediately before the call; a real design must define revocation, time-of-check/time-of-use behavior, separation of duties and the trusted target's enforcement. The tests demonstrate these local contracts only. Do not present this exercise as your own historical production experience.

Extend it by adding an expected ERP record version, a worker lease, a policy-version binding and a deterministic fake clock. Explain why a successful local SQLite transaction cannot roll back a transaction already committed in the separate ERP database.