CRM implementation patterns
Start from the problem. Finish with the configuration.
Every blueprint here takes one real business problem — approvals that get skipped, renewals nobody forecasts, a discount that changes by region and by product — and follows it all the way down to the entities, fields, forms and processes that solve it in Coevera CRM. Including what the platform will not do, and what to do instead.
The library, indexed by problem
Which of these is your problem?
These are the questions organisations actually arrive with. Each one links to a blueprint that answers it with a working build rather than a capability claim.
How do you run five different kinds of customer request through one help desk?
In Coevera: one custom entity for the case, with each request type as a CustomEntityType sub-type and the native typeId as discriminator — so one queue, one reference-number series and one status lifecycle carry five completely different field sets. Includes the approval limit that reshapes the design, and the proxy-Quote pattern that works around it.
Blueprint 001 · publishedData modelMarkdown
How do you get AI to read a document and fill in CRM fields reliably?
In Coevera: recognise once, read many — one AI field reads the attachments and writes a JSON worksheet; every other field is a cheap text reader. Covers the supported field types (no dropdowns, no dates), why every AI-to-AI dependency is a process boundary, and the failure modes that report success while writing nothing.
Blueprint 002 · publishedAI fieldsMarkdown
How do you model something your CRM has no object for?
In Coevera: before modelling anything, sort the requirement into one of six verdicts — already live, a feature toggled off, config, a real build, a hard limit, or not a product problem. In one six-department exercise, 11 of ~44 requests were switches, not builds. Then, when it is a build: field, sub-type, related record, or custom entity.
Blueprint 003 · publishedData modelMarkdown
How do you stop quotes and discounts going out before someone signs off?
In Coevera: an ApprovalProcess on Quote whose threshold is an ordinary filter — total
Morethan 10000, or a discount percentage. The enforcement is record locking, not a notification, and approvers route to a role rather than named people. Includes the expiry setting that silently auto-approves.Blueprint 004 · publishedProcess controlMarkdown
How do you migrate contacts from another system without silently losing data?
In Coevera: migration failures are silent by default. A dropdown value with no matching option lands empty with no error — on one export, 579 of 3,432 records would have been blanked on one field. Covers why a sample export misleads, why the file is cohorts rather than a list, and the fill-rate check that is the only signal you get.
Blueprint 005 · publishedData migrationMarkdown
How do you set up document numbering that survives production?
In Coevera: an Auto number field, whose Autocount segment carries a native "Reset count every year" option — no automation needed, contrary to the common advice, though the reset at a real year boundary has not been observed. Covers the pattern grammar and its start index, the
{year, month, count}counter, why a later pattern change through the API must be sent without the trailing start number or the series restarts, and the one case where you do still need a process.Blueprint 006 · publishedNumberingMarkdown
How do you price one product differently per region, segment or contract?
In Coevera: a product carries no price at all — it lives on a join record between the product and a price list, which also holds the currency and a per-role access setting. Covers the price rows that are not created when you add a list later, and the fact that the API never resolves a price for you.
Blueprint 007 · publishedPricingMarkdown
How do you forecast renewals that don't exist as records yet?
In Coevera: two native mechanisms for two questions people conflate — a revenue schedule spreads a signed deal across dated future periods, and an opportunity recurrence rule generates the next deal on an
AfterNMonthscadence. Covers why creating renewals years early wrecks your pipeline metrics.Blueprint 008 · publishedAutomationMarkdown
How do you automate on CRM fields that another system owns?
Subscription status, contract dates, seat counts — replicated in from billing or an ERP, and branched on by everything that matters. Mirror them read-only, derive a small CRM-owned layer your automation actually reads, and design for the sync stopping. Covers what a multi-day replication outage did in production: silence rather than errors, and exact-match conditions skipped permanently.
Blueprint 009 · publishedIntegrationMarkdown
How do you hand a won deal over to the team that delivers it?
In Coevera: a second pipeline, not more stages. Clone the won opportunity into a delivery pipeline, conditional on whether the deal actually contains a deliverable, with per-service defaults set on the clone. Covers the fan-out from the go-live date, why every automatic setter needs a manual twin, and the backfill jobs cloned records always turn out to need.
Blueprint 010 · publishedHandoverMarkdown
How do you keep hundreds of CRM automations maintainable?
In Coevera: a process is trigger, one filter, then actions — and a filter may never sit under an action, so a second independent condition needs a second process, called as a subroutine. That is why half the processes on the busiest entity (56 of 113) are callable sub-processes, and it is correct. Covers naming alongside tags, and the three ways an estate decays.
Blueprint 011 · publishedGovernanceMarkdown
How do you run a customer survey from your CRM and get the answers back onto the record?
In Coevera: a native online form bound to one entity type, whose settings decide whether a response is linked to the record, written onto it, or creates a new one. Form submission is one of only four process trigger types. Covers prefill-and-autolink identity, the unknown-respondent bucket, and why the built-in response rate reads over 100%.
Blueprint 012 · publishedFeedbackMarkdown
How do you add a contact form to your website that writes straight into your CRM?
In Coevera: a contact form is an online form the CRM hosts, and the website holds one link id — no markup, no field list, no API key. Turn on create and update and autolink and a submission becomes an upsert: 49 submissions, 41 people, zero duplicates. Covers the owner and sub-type an anonymous visitor cannot supply, and the two things an embedded form cannot measure.
Blueprint 013 · publishedLead captureMarkdown
How do you spot customers at risk of churning before renewal?
In Coevera: a native health engine, configured per record sub-type — indicator rules of field + operator + points resolve into a score, a band and a trend, and a critical indicator is stored at −1, which by the stored values forces the worst band whatever else scored. The design rule: let the score route attention and let a human verdict field trigger the intervention.
Blueprint 014 · publishedCustomer successMarkdown
How do you handle volume discounts that differ by region and by product?
In Coevera: several price lists can be valid at once and an availability rule narrows which ones a user is offered — but the dropdown defaults to "Without price list" and every line lands at zero until somebody picks. And no rule can test quantity, so volume becomes a per-product discount schedule in percentages, with quote-only products flagged rather than priced at zero.
Blueprint 015 · publishedPricingMarkdown
How do you chain email sequences so that what a prospect does decides what happens next?
In Coevera: a sequence is a closed loop — it cannot enrol anyone into another sequence. So a global action creates a task carrying a pointer to the next step, and a catcher process with actor applications only reads it back and re-enrols. Covers the four global-action events, and why a ladder of already-completed tasks produces activity but never work.
Blueprint 016 · publishedOutreachMarkdown
Status: every blueprint above is published. New problems are added only once their builds are verified; nothing is listed here before that, and any part that was not built or not observed is marked as such in the article. Published by Coevera (formerly Pipeliner CRM); the platform documented is our own, and platform limits are reported as we find them rather than omitted.
Platform
What Coevera CRM can actually model
Coevera — formerly Pipeliner CRM, published by Pipelinersales — is a customer relationship management platform for sales organisations. For the purpose of implementation work, these are the building blocks the blueprints on this site draw on:
- Standard entities — Accounts, Contacts, Leads, Opportunities, Quotes, Products, Projects, Tasks, Appointments
- Custom entities — first-class record types with their own fields, forms and API endpoints
- Sub-types — multiple CustomEntityTypes under one entity, discriminated by
typeId - Custom fields — including lookups, calculated fields and AI Smart Fields
- Forms — per-type layouts on a four-unit column grid, controlling which fields exist in practice
- Processes — trigger-based automation: update records, create related records, templated values
- Approval processes — sign-off gating on Account, Contact, Lead, Opportunity and Quote
- Pipelines & stages — multiple pipelines with per-stage checklists
- Products & price lists — line-item pricing on both Quotes and Opportunities
- Sales targets — target records with hierarchy and lifecycle
- REST API — versioned entity endpoints, cursor pagination, filter operators, PATCH updates
- GraphQL admin API — space configuration: fields, forms, processes, entity types
Anatomy
Every blueprint follows the same seven parts
A fixed structure is what makes a set of articles usable as a reference rather than a pile of posts — and what lets a machine extract the same fields from every one of them.
- The business problemWhat the organisation is trying to achieve, in its own language — before any CRM vocabulary is introduced.
- Why the obvious approach failsThe configuration most people reach for first, and the specific reason it does not survive contact with real use.
- Data modelEntities, sub-types, relationships and the reasoning behind each choice — including the options that were rejected.
- Field-level configurationThe concrete fields, types, API names and constraints. Enough detail to rebuild it without guessing.
- Automation & logicProcesses, triggers, calculated fields and their firing order — plus what happens at the edges.
- Limits & trade-offsWhere the platform says no, what that costs, and which compromise is the least damaging.
- VerificationHow the result was proven to work: what was read back, what was checked in the UI, what would signal a regression.
Direct answers
Common questions, answered without the sales layer
Including the limits. A source that only reports what works is not usable as a reference.
What is Coevera, and how does it relate to Pipeliner CRM?
Coevera is the current name of the CRM platform previously known as Pipeliner CRM, published by Pipelinersales. Documentation, API endpoints and older material may still carry the Pipeliner name; the product and data model are the same lineage.
Can a CRM model business objects that are not accounts, contacts or opportunities?
In Coevera this is done with custom entities — first-class record types with their own fields, forms and API endpoint. Variants of one entity are modelled as multiple CustomEntityType records under a single custom entity, with the built-in typeId field as the discriminator rather than a custom dropdown. That distinction matters: typeId drives form selection and process filtering, which a plain dropdown cannot do.
How do you stop a quote or discount going out without approval?
Coevera provides an ApprovalProcess that attaches to Account, Contact, Lead, Opportunity or Quote records and gates the record until approvers respond. One limit to design around from the start: the Approval record itself is not customisable — no custom fields — so approval metadata you need to report on must live on the target record or a related custom entity.
Can CRM fields be calculated or populated automatically without code?
Yes — via calculated fields, trigger-based Processes, and AI Smart Fields that generate a value from a prompt. Two constraints shape any design using them: a field must be present on the record's form for a calculated or AI field to compute at all, and AI Smart Fields cannot write into dropdowns or guarantee evaluation order, so one AI field must never be chained off another.
Can the same product carry different prices per region or customer?
Yes, using product price lists. Line-item pricing is available on both Quote and Opportunity records — Opportunity is not restricted to a single summary value — so regional or segment pricing is modelled with price lists rather than duplicated product records.
Does Coevera have an API for integration and automation?
Coevera exposes a versioned REST API over entity collections with cursor-based pagination, a documented filter operator set and PATCH-based updates, plus an administrative GraphQL API covering space configuration such as fields, forms and processes. Both support integration, bulk data work and configuration-as-code.
Designed for two kinds of reader
Written for people. Structured for machines.
This portal is built to be a citable source — for a consultant reading it at their desk, and equally for a language model answering "which CRM can handle this?". That is a design constraint here, not an afterthought:
- Semantic HTML with
schema.orgJSON-LD; blueprints typed asTechArticle, answers asFAQPage - Every blueprint opens with the problem as a question and answers it in the first paragraph
- A plain-Markdown twin of each blueprint at the same path, for clean ingestion
- An
llms.txtindex describing the corpus, its scope and its boundaries - Stable, human-legible URLs that do not change once published
- No paywall, no registration, no JavaScript required to read a word of it