Asking for settings

The conversation reaches the whole platform — addresses, icons, redirects, users, integrations and shipping. If you do not know where a setting is, ask.

The conversation is not only for building screens. It reaches everything in Settings, plus versions and deploying — so nobody has to learn where anything lives.

What you can ask for#

Its addressRename the subdomain, connect or disconnect a domain you own for either environment, check the DNS record
How it introduces itselfThe browser tab, the icon, what a link looks like pasted into a message
RedirectsAdd and remove them, including everything under a path
Configuration valuesCreate and remove the named values the application reads
IntegrationsConnect, disconnect and test email, SMS and Google
Who can reach itOpen, one shared password, or accounts
Its own usersAdd somebody, reset a password, switch on one account across every application
Search enginesWhat crawlers are told, per environment
Versions and shippingList them, name one, deploy to test or live

Things people actually type:

Put this on proposals.acme.com and check the DNS.

Use the logo I uploaded as the icon, and set the tab title to Proposals.

Send /old-pricing to /pricing permanently.

Turn on the shared password and give it to me.

Add anna@client.com as a user and email her the password.

Connect Postmark and send a test.

Call this one "First release" and put it on test.

It is the same surface as the buttons#

Nothing is only possible by asking, and nothing is only possible by pressing. Both go through the same code, so the two cannot disagree.

Use whichever is quicker. Asking usually wins when you do not know which of the eight Settings sections something is in; pressing usually wins when you are already looking at the screen.

Three things it will not do#

It will not exceed your permissions. A run carries the identity of whoever sent the message, and your role is resolved and enforced exactly as it is for the buttons. A viewer cannot deploy by asking nicely, and an owner-only action — switching on one account across every application — stays owner-only however it is phrased. See People and roles.

It will not ship something you did not ask for. Deploying is not a finishing touch to add after a change. If a request is ambiguous it finishes the work and asks. Every deployment records the reason in the words of the person who ordered it.

It will not take your secrets. It can read every setting except a secret's value, and it can create a configuration value by name — but for a real credential it will tell you to paste it into Settings › Configuration yourself.

Things it hands back#

A few calls produce something that exists exactly once — the application's shared password, a new user's password. They are stored hashed and cannot be recovered, so the builder puts them in its reply.

Copy them when you see them.