Chapter 8

Production flight

How writes work, how to switch Production mode on and off, the checklist to use before you approve a card, and how to check the result.

When to use Production mode

WARNING · Read this first

In Production mode, pressing Approve changes a real system: it creates or updates a Salesforce record, posts a Slack message, or opens a GitHub pull request. Cockpit has no undo. If you approve the wrong thing, you undo it yourself in that system. Until the test drive is complete, use Production mode only against the throwaway accounts from chapter 3.

"Production" here is the name of a Cockpit mode, not a statement about the org. A free Developer Edition org can be used in Production mode, and a real production org can be used in Sandbox. The risk is set by what is connected, not by the mode's name.

Stay in Sandbox for everything in chapter 7.
Switch to Production mode only for a specific write you mean to make, and switch back afterwards.
New accounts start in Sandbox, and every write needs a card.

How a write works

1You ask for a changeIn Production mode.
2The Copilot proposes itA write tool is offered only if the mode allows it.
3An approval card appearsExact input, target, fingerprint. Valid for 10 minutes.
4You press ApproveCockpit re-checks the mode and re-reads the target.
5The write is sent once30-second limit. Never retried.
6The result is reportedDone, refused (nothing changed), or not confirmed (check the system).

Illustration The path of a write. Each stage can stop it. Nothing is written before the fourth step.

The write actions in this edition
Action	What it does	What it cannot do
Salesforce: create	Creates one record of an object you name, with the field values on the card.	Values are plain text, numbers, true or false, or empty. At most 100 fields. No delete.
Salesforce: update	Updates one record, by its Id, with the field values on the card.	One record at a time.
Slack: post	Posts one message to a channel, as you.	Nothing is posted without a card.
GitHub: open a pull request	Creates a new branch named cockpit/... from the base branch, commits the files on the card, and opens a pull request.	Never pushes to an existing branch. Never merges. If the branch name exists, it stops and tells you to choose another.

These are switched on in stages (GitHub pull requests, then Salesforce records, then Slack posts). If you ask for a write whose action is not on yet, the Copilot says it has no write action for that, and nothing is changed. The tag on the Connectors card ("Read only (no write actions yet)") tells you in advance.

Sent once. A write has a 30-second limit and is never retried.
Refused means unchanged. If the system refuses (an HTTP 4xx), the answer says "... refused the change (HTTP 4xx), so nothing was changed." with the system's reason.
Not confirmed means check. If the connection drops, times out, or the system errors (5xx), the answer says the system "did not confirm the change ... so the record may or may not have been applied. Cockpit did not try again. Tell the user to check ... before asking for it again." Do exactly that: look in the system before you ask again.
The target is checked twice. It is named on the card, and read again when you approve. If it moved, the write is not sent: "approved for X, but it would now go to Y. Nothing was changed."
A tightened mode cancels it. Switching to Sandbox, or switching that connector's writes off, after a card appears makes approving refuse with "Mode changed, nothing was changed."
Where a write cannot start, no card appears and the answer says why, for example when the org is not connected, GitHub is not connected, your GitHub login cannot push to that repository, or the repository is archived.

Switching Production mode on and off

Click the mode chip.
You should see The mode panel opens with the master switch Production mode (read + write), off.
Turn the master switch on.
You should see A confirmation: "Switch to Production mode (read + write)?" It says changes are possible where a write action exists, every change still asks your approval, it does not describe the connected org, and you can switch back at any time.
Click Switch to Production mode. To back out, click Stay in Sandbox.
You should see The chip turns amber and says "Production: read + write". The panel's connector rows read "can write, each write asks for approval" (or "read only (no write actions yet)" for a connector with none).
To narrow it, turn off the switch of any connector you do not want to write to.
You should see That row reads "read only (you switched writes off)".
When you are done, turn the master switch off.
You should see The chip returns to Sandbox. No confirmation is asked.

[Screenshot: The Switch to Production mode confirmation]Figure 33

Figure 33. The Switch to Production mode confirmation. Capture details are item 33 in the list of screenshots to capture. Call-outs to draw: 1 Confirmation text; 2 Switch to Production mode; 3 Stay in Sandbox.

CAUTION

A chat made Sandbox from its menu, or with an org attached, stays Sandbox even when the account is in Production mode. Start a new chat to write.

Before you approve: the checklist

Run through this on every card. It takes under a minute, and the card is built so that every answer is on it.

Before approving a write checklist

Whose system is this? The card's last words name the target: the Salesforce org (name and address), the Slack workspace, or the GitHub repository and base branch. Is that the one you mean? Do not rely on the chat's org chip; read the card.
Is it the right kind of system? A throwaway Developer org, or something real? If real, stop and ask whether this change has been agreed.
Read "Exactly what will run" to the end. For Salesforce: the object, the record Id for an update, and every field and value. For Slack: the channel and the full message text. For GitHub: the repository, the new branch name, the title and every file path and its content.
Is it one thing? A Salesforce change touches one record. If you asked for ten, expect ten cards.
Do the values match what you asked? A wrong Id, a wrong amount, a name misheard by the microphone: the card shows what will be sent, not what you meant.
Does the blast radius line say what you expect? It reads "Writes to <target>".
For a Slack post: is anything in the message confidential? Everyone in the channel will see it as coming from you.
For a pull request: is the base branch right? The pull request is only a proposal, but the new branch and its commit are created on approval.
Is it still wanted? Cards expire after 10 minutes. If you were interrupted, deny it and ask again.
In doubt, Deny. Denying writes nothing, and you can ask again with a clearer request.

[Screenshot: A real approval card for a Salesforce create]Figure 34

Figure 34. A real approval card for a Salesforce create. Capture details are item 34 in the list of screenshots to capture. Call-outs to draw: 1 Summary and target; 2 Exactly what will run; 3 Blast radius; 4 Approve and Deny.

WARNING

Never approve a card you have not read to the end. Text in your systems (a record, a log, a pull request description) is treated by the Copilot as data, but a card is the last line of defence if something odd got through. The card shows the exact input, and that is what runs.

ADVISORY

"Always allow" is not offered for writes. Every write is decided on its own.

Three first writes on the test accounts

Do these in your throwaway orgs, one at a time, with the checklist above. Each one is small, and each is something you can undo by hand.

A Salesforce record

Switch to Production mode (see above). Start a new chat and pick org 1.
Ask: Create an Account named Cockpit Test Drive One.
You should see An approval card: "Create a Account in Salesforce with Name (Salesforce org ...)" and the input {"sobject": "Account", "fields": {"Name": "Cockpit Test Drive One"}}.
Run the checklist. Press Approve.
You should see The card changes to approved, and the Copilot reports the new record's Id.
In Salesforce, open Accounts and find it.
You should see Exactly one Account named Cockpit Test Drive One.
Delete it in Salesforce when you have finished. Cockpit has no delete action.

A Slack message

Ask: Post "Cockpit test drive: hello" in #cockpit-practice.
You should see A card naming your Slack workspace and the full text.
Run the checklist, press Approve, and look in the channel.
You should see The message appears, as you.

A GitHub pull request

Ask: Open a pull request in yourname-cockpit-test/cockpit-practice that adds docs/hello.md with one line of text.
You should see A card naming the repository and the base branch, with the new branch name cockpit/... and the file.
Run the checklist, press Approve.
You should see A pull request appears on GitHub from the new branch. It is open; nothing has been merged.
Close the pull request and delete the branch on GitHub when you have finished.

[Screenshot: The Account found in Salesforce after approval]Figure 35

Figure 35. The Account found in Salesforce after approval. Capture details are item 35 in the list of screenshots to capture. Call-outs to draw: 1 Account name; 2 Created date.

Also try Deny once, on any card. Check that nothing was written.

Afterwards

Check the result in the system, not only in the chat.
The Modes page lists your recent mode changes, and the count of requests held back by a mode in the last 30 days.
The Approvals tab of the Brain panel and the chat itself keep each decided card, with who decided and when.
Switch back to Sandbox.

Production flight checklist

I read the card to the end before each Approve.
I checked the result in the system after each write.
I denied one card and nothing was written.
I switched back to Sandbox.
I removed what I created in the test accounts.

TO BE CONFIRMED · Production writes in the live service

The owner has agreed to switch the write actions on in the live service in stages, after the live write journeys have passed. Which ones are on when you read this is shown by the capability tags on your Connectors page, not by this manual.