Changing things by asking

Lesson 34 of 40 · 6 min

Reading is where the conversation earns its place; writing is where it starts saving time. The difference is a key with write scopes, and a habit worth forming before you turn one on.

A real exchange, start to finish

Captured against your org on 2026-08-19. Four asks, in the order somebody actually works:

You: Find me the biggest open enquiry that has had nothing logged on it.

It came back with Business Loan — Ishaan Pandey — ₹92,78,299, at Contacted. One question, one record, no filter built.

You: Log a note on it: spoke to them, they are waiting on a valuation.

You: Raise a task to call them back on Friday.

You: Actually make that high priority, it is our biggest open case.

That last one is the whole argument. Changing your mind about something you made ten seconds ago is the commonest second instruction anybody gives, and it is exactly where a screen makes you work: find the task again, open it, change one dropdown, save. Here it is a sentence, and the thing it refers to is understood.

What it wrote

Three writes, one conversation.

What	On	Value
A note	the enquiry	what was learnt on the call
A task	the same enquiry	`medium`
Then an amendment	that task	`high`

A note

On: the enquiry
Value: what was learnt on the call

A task

On: the same enquiry
Value: medium

Then an amendment

On: that task
Value: high

Both records landed on the enquiry itself — the note and the task carry the deal's id — which is the difference between a trail and a pile. It is the same distinction Notes, tasks and the activity trail drew: a note is what somebody observed, a task is what somebody committed to.

Everything it does is an ordinary write

There is no special “AI wrote this” mode. The note is a note. The task is a task. They appear on the record, in the lists, in the exports, and — this is the part that matters — they are subject to the same automations as anything else. A task created this way can trigger a workflow, exactly as one typed by hand would.

Which cuts both ways, and is the reason for the next section. A bulk change made in one sentence is a bulk change: if fifty records move stage, whatever watches that stage wakes up fifty times.

Before you turn write scopes on

Read first, write second. Ask it to show you what it is about to change, then tell it to change that. Two sentences, and the first one is free.
Know what is watching. Before a bulk edit, know which workflows trigger on the thing you are editing. The first five minutes: call-back and routing is the lesson: three workflows can wake on one event and none of them knows about the others.
One client per connection. The tools are identical across orgs and nothing warns you which one you are in.
Nothing is secretly reversible. A delete is a delete. There is no undo in a sentence.

What it leaves behind

The session above created a note and a task and then removed both — and the removal is as visible as the creation was. Every write carries who made it, and a key's writes are attributed to that key rather than to a person.

So name your keys after what they are for. “partner-tooling” in an audit trail tells a client's admin something. A key called “test” tells them nothing, six months after whoever made it has forgotten.

Change one thing — do the four

Give your demo org's key write scopes.
Run the same four asks: find your biggest untouched enquiry, log a note, raise a task, then change the task's priority.
Open the record in the browser and check all three landed where you expected.
Now delete both, by asking. Then check the record again.
If any of that surprised you, it is better to have been surprised here.

Try it

Ask it to change something across several records at once, and count the clicks you did not do.
Work out which workflow in your org would fire if you moved five enquiries to a different stage in one sentence. Then decide whether you would.

Next: Building a workflow by asking — from changing records to making something that runs on its own.