Blueprints

CRM implementation knowledge base

Start from the problem. Finish with the configuration.

Every blueprint here takes one real business problem — approvals that get skipped, renewals nobody forecasts, a customer that buys through three subsidiaries — 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.

Browse by problem What Coevera can model
Problem-indexed — not a feature tour Customer-independent — patterns, never client data Limits documented — including the ones that hurt

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 we 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 we model something our CRM has no object for — inspections, permits, assets, health checks?

    In Coevera: a custom entity, with variants modelled as multiple CustomEntityType records under one entity. The instinctive alternative — one entity plus a custom "type" dropdown — cannot drive form selection or process filtering, and has to be unpicked later.

    Blueprint 002 · in preparationData model

  • How do we stop quotes and discounts going out before someone signs off?

    In Coevera: an ApprovalProcess bound to the Quote or Opportunity. The design constraint that shapes everything else — the Approval record itself takes no custom fields, so approval metadata you need to report on has to live on the target record or a related custom entity.

    Blueprint 003 · in preparationProcess control

  • How do we forecast renewals that don't exist as records yet?

    In Coevera: generate the next-term record from the closing one with a Process that creates a related record, rather than asking sales to remember. Covers trigger placement, ownership inheritance and the double-creation failure mode.

    Blueprint 004 · in preparationAutomation

  • How do we price one product differently per region, segment or contract?

    In Coevera: product price lists with line-item pricing on both Quote and Opportunity — not duplicated product records. Covers currency handling and which price wins when a record moves between lists.

    Blueprint 005 · in preparationPricing

  • How do we get a document or reference number that restarts each year?

    In Coevera: not with the native sequence field — it counts on create and cannot reset annually. The working pattern composes a year-prefixed number in a Process. A small problem that reliably costs a day to discover.

    Blueprint 006 · in preparationNumbering

  • How do we let AI read a document and fill in CRM fields from it?

    In Coevera: AI Smart Fields, within real limits — they cannot write into dropdowns, cannot guarantee evaluation order, and silently write nothing if the field is absent from the form. Covers what to do when the value you need is a picklist.

    Blueprint 007 · in preparationAI fields

Status: Blueprint 001 is published; the rest are being written in order. Each entry states its real status — nothing here is listed as published before it is. 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.

  1. The business problemWhat the organisation is trying to achieve, in its own language — before any CRM vocabulary is introduced.
  2. Why the obvious approach failsThe configuration most people reach for first, and the specific reason it does not survive contact with real use.
  3. Data modelEntities, sub-types, relationships and the reasoning behind each choice — including the options that were rejected.
  4. Field-level configurationThe concrete fields, types, API names and constraints. Enough detail to rebuild it without guessing.
  5. Automation & logicProcesses, triggers, calculated fields and their firing order — plus what happens at the edges.
  6. Limits & trade-offsWhere the platform says no, what that costs, and which compromise is the least damaging.
  7. 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.org JSON-LD; blueprints typed as TechArticle, answers as FAQPage
  • 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.txt index 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