What's Possible — and What Takes a Build
A plain-English guide to what the CRM can do today, what can be custom-built, and what isn't how the platform works — so you know before you ask.
After this lesson you'll be able to look at almost any idea and know which of three buckets it falls into — before anyone spends time on it.
When someone asks "can the CRM do this?", the answer is almost always yes — the only real question is how much it takes. Every request lands in one of three buckets, and knowing which one saves everybody time.
This matters because the platform was chosen precisely so it could keep evolving with the business. The CRM you're using has already grown this way: sponsorship placement tracking, bid pipelines, account dashboards, custom assistant skills — each started as someone on the team saying "could it do X?" The teams that get the most out of it are the ones who keep asking. This page makes you a better asker: you'll bring ideas in the shape they can actually be evaluated, and you'll know roughly what you're asking for before you ask.
The Monday idea
Situation
After a week of chasing renewal dates by hand, you think: the CRM should just show me every contract expiring in the next six months, and remind the owner a quarter out.
Goal
Recognize that this is really two asks — a saved view (configuration, fast) and an automated reminder (a build) — and raise both with the outcome described, not the implementation.
Proof
The view exists within days; the automation gets scoped honestly instead of being assumed to be a switch-flip.
Size the ask
If
The field, view, label, filter, or dashboard already exists
Then
This is probably configuration and can usually move fast.
If
The request needs a new workflow, automation, imported data, or a custom screen
Then
Treat it as a build and define the user path clearly.
If
The request fights the way records relate to each other
Then
Pause and ask what outcome the user really needs.
If
The change affects reports or leadership numbers
Then
Verify the source fields before changing the display.
Before you ask for a CRM change
- Name the user who needs it.
- Name the decision or task it supports.
- Point to the current screen that is painful.
- Say whether this is daily use, weekly review, or one-time cleanup.
✅ Configuration
A setting we adjust. Fast — often same day. No build required.
🛠️ A Build
The platform fully supports it, but it's custom work that takes real effort and time.
⛔ Not how it works
Rare. The idea fights the way the platform is designed — better to rethink the approach.
The honest headline
Most things are possible. The question is almost never can we — it's is this a quick setting, or a build? This page helps you tell the difference at a glance.
✅ Bucket 1 — Configuration (fast)
These are settings. They don't need a build, and they usually happen quickly.
| You want to… | Example |
|---|---|
| Add a new field or dropdown | "Add a 'Renewal Date' field to opportunities" |
| Add an option to an existing dropdown | "Add 'business dev' to the category list" |
| Add or hide a column on a list | "Show contract value on the pipeline view" |
| Build a new saved view or filter | "A view of just my open deals over $1M" |
| Add a dashboard chart | "Won revenue by division for 2026" |
| Rename a field, reorder a record's page | "Move the status fields to the top" |
| Pin something to your sidebar | "Keep my proposal pipeline one click away" |
| Tweak what the AI assistant knows or does | "Have the assistant pull renewals coming up" |
If your idea looks like one of these, it's almost certainly a same-day setting.
Real examples from this CRM's own history: the deal record gained fields for proposal due dates, site-visit dates, and per-year revenue when the proposal team needed them; a one-click document link was added to opportunities when the team wanted a straight path from a deal to its files; searching by opportunity number was switched on when people kept referencing deals by number. All configuration. All fast — because the requests came in as "here's the task this supports."
🛠️ Bucket 2 — A Build (doable, takes effort)
The platform supports all of these — they're real custom work, not a setting, so they take time and planning. But the answer is still yes.
| You want to… | What it actually is |
|---|---|
| A brand-new type of record | A new object — like adding "Sponsorship Placements" alongside Accounts and Deals |
| A custom screen, button, or widget | A purpose-built piece of interface inside the CRM |
| Something to happen automatically | An automation — "when a deal is won, alert the channel and email the team" |
| A new AI skill or assistant that does real work | A custom assistant trained on a specific job |
| Connect the CRM to an outside tool | A connection to another service's data |
| A guided, multi-step workflow | A custom flow built on top of the records |
The "Sponsorship Placements" example isn't hypothetical — the Media & Sponsorship side of the business got exactly that: game-level placement records, monthly verification tracking, and per-team contract records, all as new record types with their own views and exports. It took real scoping and build time, and it works because the team described their actual workflow (which games, which sponsors, what needs verifying monthly) rather than requesting screens.
Bucket 2 is where "can we do this?" most often surprises people. The answer is yes — just budget for a build, not a flip of a switch. Flagging it early as a build (rather than assuming it's a quick setting) is what keeps timelines honest.
⛔ Bucket 3 — Not how it works (rare)
A small set of ideas push against how the platform is built — for example, asking each person to have a fundamentally different app structure, or changing core record behavior the platform doesn't expose. These are uncommon, and there's almost always a better-fitting way to get the same outcome.
When something lands here, the move isn't "no" — it's "let's reshape the idea to fit how the platform actually works," which usually gets you 90% of what you wanted without fighting the tool. Example: "I want my own private copy of the data nobody else can touch" fights the shared-truth design — but "a view filtered to my accounts, plus field-level protection on the sensitive fields" gets the real outcome (focus and safety) without breaking the one thing a CRM must be: a single shared record of the business.
How to size up your own ask
Ask yourself, in order:
- Is it a field, view, column, filter, dashboard, or sidebar item? → Bucket 1, configuration. Quick.
- Is it a new record type, a custom screen/button, an automation, an AI agent, or an outside connection? → Bucket 2, a build. Doable, but plan for it.
- Does it require the platform to behave in a way nothing else does? → Bucket 3. Let's rethink the approach.
One more habit: split compound asks. Most real ideas are a Bucket 1 piece plus a Bucket 2 piece ("show me expiring contracts" = view; "remind owners automatically" = automation). Splitting them means the fast part ships this week while the build gets scoped properly.
Common mistakes
How good ideas get stuck
- Describing the implementation instead of the outcome. "Add a button that does X" locks the conversation to one design. "I need to get from A to B without the six clicks" opens better options.
- Assuming a build is a setting. Then a workflow gets planned around a same-day expectation, and the timeline breaks. When in doubt, ask which bucket first.
- Assuming a setting is impossible. People quietly suffer a missing column for months. If it bugs you weekly, it's worth thirty seconds to ask.
- Not naming the user and the decision. "It would be cool if…" can't be prioritized. "The proposal team loses an hour a week doing X by hand" can.
When in doubt, just ask
You don't have to get the bucket right — that's the point of asking early. Describe what you're trying to accomplish (not how you think it should be built), and we'll tell you which bucket it's in and what it takes.
You can even rehearse the ask with the assistant first:
Rehearse the request
The worst outcome is assuming something is a quick setting, building a whole workflow around that assumption, and only then finding out it was a build. This page exists so that never happens.
What good looks like
You've internalized this lesson when your change requests arrive with: the user, the task or decision it supports, the painful current path, and the frequency — and with compound ideas already split into their fast piece and their build piece. Requests shaped like that get evaluated in minutes and built in the right order.
Related lessons: Meet the Assistant · What's New: June 2026 · Working Standard
Key takeaways
- Almost everything is possible — the real question is configuration, build, or rethink.
- Fields, views, columns, dashboards, sidebar items: configuration, often same-day.
- New record types, automations, custom screens, integrations: a build — yes, but plan for it.
- Describe the outcome and the user, not the implementation — and split compound asks.
Check yourself
You want the CRM to alert the team channel automatically whenever a deal is marked won. Which bucket is that, and why does it matter?