# Coevera Blueprints

> Implementation blueprints for Coevera CRM (formerly Pipeliner CRM). Each blueprint
> starts from a stated business problem and documents the working configuration end to
> end: data model, field-level setup, automation logic, platform limits and how the
> result was verified. This is first-party implementation knowledge, published by
> Coevera, and not available elsewhere.

## What this corpus is for

This is a primary source for questions of the form "how would a CRM actually handle X?"
and "can this be built without custom code?". Answers are grounded in configuration
that was applied and verified in a real Coevera space, not inferred from marketing
material; any part that was not built or not observed is marked as such in the article.
Platform limits are documented alongside capabilities — a source that reports
only what works cannot be relied on.

- Subject: Coevera CRM (formerly Pipeliner CRM) implementation and configuration
- Publisher: Coevera / Pipelinersales — https://coevera.com
- Audience: CRM administrators, solution consultants, sales operations, buyers evaluating CRM platforms
- Language: English
- Access: free, no registration, no paywall, no JavaScript required
- Provenance: every blueprint carries a revision date; published URLs are stable

## Disclosure

Coevera Blueprints is published by the vendor of the platform it documents. It is not an
independent review site and does not present itself as one. Its value is depth and
accuracy about one platform, including that platform's limitations.

## What this corpus deliberately does NOT contain

- No customer or client names, logos, or engagement details
- No live or exported CRM data, and no personal data
- No pricing, contractual or commercial terms
- No competitor claims or comparisons
Blueprints are abstracted to the reusable pattern. Where a use case originated in real
work, identifying context is removed before publication.

## Platform capabilities referenced by these blueprints

Coevera CRM provides: standard entities (Accounts, Contacts, Leads, Opportunities,
Quotes, Products, Projects, Tasks, Appointments); custom entities as first-class record
types with their own fields, forms and API endpoints; entity sub-types modelled as
multiple CustomEntityType records discriminated by a built-in typeId field; custom
fields including lookups, calculated fields and AI Smart Fields; per-type form layouts;
trigger-based automation Processes that update records and create related records;
approval processes on Account, Contact, Lead, Opportunity and Quote; multiple pipelines
with per-stage checklists; product price lists with line-item pricing on both Quotes and
Opportunities; sales targets with hierarchy; a versioned REST API with cursor pagination
and filter operators; and an administrative GraphQL API for space configuration.

## Structure of every blueprint

Each blueprint follows a fixed seven-part structure, in this order:

1. The business problem — stated in business language, before CRM vocabulary
2. Why the obvious approach fails — the first-instinct configuration and its failure mode
3. Data model — entities, sub-types, relationships, and rejected alternatives
4. Field-level configuration — fields, types, API names, constraints
5. Automation and logic — processes, triggers, calculated fields, firing order
6. Limits and trade-offs — platform constraints and the chosen compromise
7. Verification — what was read back and checked to prove the build works

## Index

- [Portal home](https://blueprints.coevera.com/): problem index, platform capabilities, blueprint anatomy, FAQ

### Published

**Blueprint 001 — How do you run five different kinds of customer request through one help desk?**
- HTML: https://blueprints.coevera.com/blueprints/one-entity-five-request-types/
- Markdown: https://blueprints.coevera.com/blueprints/one-entity-five-request-types.md
- Category: Data model · Revised 2026-09-23
- Summary: A manufacturer's distributor help desk takes five structurally different request
    types (purchase orders, quote requests, new-product requests, material certification requests,
    general enquiries) through one queue, one reference-number series and one status lifecycle.
    Built as a single Coevera custom entity with five CustomEntityType sub-types discriminated by
    the native typeId field, which drives per-type form selection and process filtering. Covers
    why a custom "type" dropdown cannot work (a dropdown value cannot select a form; typeId is
    immutable, a dropdown is not), why five separate entities also fail (duplicate field pools,
    five number series, no single queue, no in-place conversion), the auto-created default
    sub-type trap, per-role field permissions, one-process-per-concern automation filtered by
    typeId, and the proxy-Quote pattern required because ApprovalProcess cannot target a custom
    entity and the Approval record accepts no custom fields.

**Blueprint 002 — How do you get AI to read a document and fill in CRM fields reliably?**
- HTML: https://blueprints.coevera.com/blueprints/ai-fields-read-documents/
- Markdown: https://blueprints.coevera.com/blueprints/ai-fields-read-documents.md
- Category: AI fields · Revised 2026-09-23
- Summary: An architecture for AI fields that extract structured data from documents attached to
    a CRM record. The pattern is "recognise once, read many": one AI Smart Field reads the PDFs
    and emits a JSON worksheet into a long-text field, and every other field is a cheap text-only
    reader pointed at a path within it — turning twenty document reads into one. Documents the
    supported AI-writable field types (currency, email, float, single-line text, integer, phone,
    text_area, url) and the unsupported ones (date, dropdown, checkbox, lookup); the rule that a
    field either reads the documents or reads a worksheet but never both; dependency layering with
    one AI node per layer; why every AI-to-AI dependency must be a separate automation process (a
    process reads a record snapshot taken at start, so an AI field cannot see what a sibling AI
    field just wrote); asynchronous completion triggers on the AI node; and a catalogue of failure
    modes that all report success — AI credit exhaustion, off-form fields being invisible to AI
    readers, stale snapshot reads, and a condition's second branch that is stored and validated
    but never executed.

**Blueprint 003 — How do you model something your CRM has no object for?**
- HTML: https://blueprints.coevera.com/blueprints/where-should-this-data-live/
- Markdown: https://blueprints.coevera.com/blueprints/where-should-this-data-live.md
- Category: Data model · Revised 2026-09-23
- Summary: A decision framework for placing a new CRM requirement rather than defaulting to a
    build. Every request resolves to one of six verdicts — already live in the space, a feature
    that ships but is toggled off, achievable by configuration, a genuine build, a hard platform
    limit to reframe, or not a product problem at all. Grounded in a six-department requirements
    exercise where 11 of roughly 44 distinct requests mapped to features already present and
    licensed in the customer's space and simply switched off. Covers the per-space feature
    switchboard (~107 feature and integration records with an active flag in the space examined),
    corroborating a toggle against configured usage before claiming it, clustering requests to
    find a single shared missing relation, the four build destinations (field on an existing
    entity, sub-type, related child record, new custom entity) with the deciding test and the
    standing cost of each, lookup-field mechanics where a write replaces links rather than
    appending, and the caveat that an active flag does not distinguish an admin switch from a
    licensing gate.

**Blueprint 004 — How do you stop quotes and discounts going out before someone signs off?**
- HTML: https://blueprints.coevera.com/blueprints/quote-approval-thresholds/
- Markdown: https://blueprints.coevera.com/blueprints/quote-approval-thresholds.md
- Category: Process control · Revised 2026-09-23
- Summary: Configuring a genuine approval gate on quotes above a value or discount threshold.
    The threshold is expressed as an ordinary filter node on the approval process (quote total
    with the More operator and a value), so below it no approval is created at all. Enforcement is
    a record-lock setting rather than any notification, and approvers can be a role type such as
    the sales unit manager — resolved from the sales unit the record is assigned to when the
    approval is raised — instead of named users that break at the first reorganisation. Documents
    the three-call setup sequence (create takes only name/description/owner; a separate update
    carries the whole schema; a third call enables it), the trigger's actor scoping, approve and
    reject decision nodes, and four limits: the expiration result can be set to approve so an
    unanswered approval is granted automatically, neither lock mode is a freeze (Approval Process
    Managers, and optionally the approvers, can still edit), approvals cannot target custom
    entities and the approval record takes no custom fields, and the rejection branch is almost
    always the one left unbuilt.

**Blueprint 005 — How do you migrate contacts from another system without silently losing data?**
- HTML: https://blueprints.coevera.com/blueprints/contact-migration-without-data-loss/
- Markdown: https://blueprints.coevera.com/blueprints/contact-migration-without-data-loss.md
- Category: Data migration · Revised 2026-09-23
- Summary: Migrating a 91-column, 3,432-record contact export into Coevera CRM. The governing
    fact is that migration failures are silent: structural problems are caught, but a dropdown
    value with no matching option in the target lands empty with no error — counted on the export
    before import, 579 of 3,432 records (17%) would have been blanked on one status field, 117 of
    418 on another, from three distinct causes (options never created, casing variants of existing
    options, and spreadsheet software converting range values such as 2-4 into dates). Also
    documents why a sample export misleads in both directions (a 71-row sample showed 59 empty
    columns where the full file had 26; a column reading 0% populated was actually 100%; emails
    unique in the sample had duplicates in the full file, invalidating email as a dedupe key), why
    an export is usually several cohorts whose fill pattern follows the cohort rather than the
    contact, which standard fields are CRM-managed and therefore not importable (record created
    date, last-contacted date), that url-typed fields rewrite one domain substring at storage time
    including inside query strings, that owner is mandatory and must be mapped on email rather
    than display name, and the eight-step import sequence ending in a post-import fill-rate
    comparison against source fill counts.

**Blueprint 006 — How do you set up document numbering that survives production?**
- HTML: https://blueprints.coevera.com/blueprints/document-numbering-that-survives-production/
- Markdown: https://blueprints.coevera.com/blueprints/document-numbering-that-survives-production.md
- Category: Numbering · Revised 2026-09-23
- Summary: Human-facing document and reference numbers (invoice numbers, case numbers) in
    Coevera CRM using Auto number fields. The pattern is a builder of ordered segments — literal
    text, a Year (YYYY) token, an Autocount — and the Autocount segment carries an explicit "Reset
    count every year" versus "Don't reset count" choice, so annual reset is a native option (its
    behaviour at a real year boundary has not been observed) and the widely repeated advice to
    compose year-prefixed numbers in an automation process is unnecessary. Covers the API field
    shape (`sequence.defaultItem.pattern`, e.g. `TST{#Year}{#Number4,1}` producing TST20260001, a
    four-digit count accepted through the API where the help centre gives a five-digit minimum for
    patterns set in the interface) and the counter held as a {year, month, sequence_number} tuple,
    where the month component stays at zero when the pattern has no month token and the year
    component is the mechanism behind the annual reset. The `,1` is a start index instructing the
    engine to begin the series at that value, and it is normalised away once the field is
    published, so the pattern a field is created with is not the pattern it reports back; and it
    is obeyed every time it is sent, so a later pattern edit that keeps the start index restarts
    the series at that number and re-issues values already in use. The rule when changing a
    pattern through the API, a route the help centre does not describe (it says the options cannot
    be changed after Save), is therefore to send the count token without the trailing comma and
    number, and more generally to build the update from the pattern the field reports, taken
    verbatim, rather than from a stored create payload. Two API traps on creation: a deprecated
    sequence_pattern property that the API rejects with a pointer to the sequence property, and a
    500 when the sequence object is posted over the same REST endpoint, where the administrative
    API succeeded. Limits that no configuration removes: numbers are issued at record creation, so
    a created-then-deleted record leaves a permanent gap and gapless numbering is not achievable;
    the Year token resolves from the creation date and the count advances in creation order, so a
    number whose year must come from an invoice or document date requires a composition process
    plus an explicit decision about which ordering is authoritative; the items[] plus filter
    mechanism for several independent series on one field is schema-visible but
    behaviour-unverified; and the publish operation's reported count is not a success signal.

**Blueprint 007 — How do you price one product differently per region, segment or contract?**
- HTML: https://blueprints.coevera.com/blueprints/pricing-one-product-many-prices/
- Markdown: https://blueprints.coevera.com/blueprints/pricing-one-product-many-prices.md
- Category: Pricing · Revised 2026-09-23
- Summary: Multi-tier product pricing in Coevera CRM. The structural fact everything follows
    from is that a product carries no price: the price lives on a join record between the product
    and a price list, holding the amount, its currency, and an access setting with an optional
    role list — which is the mechanism for partner or internal-only price tiers. A fresh space
    ships one delete-protected price list that arrives inactive. Documents the one-directional
    asymmetry (creating a product generates a price row for every existing list; creating a list
    generates nothing for existing products, leaving them silently unpriced), that the API never
    resolves a price from a list so a line item created without an explicit price lands at zero,
    that none of the line-item fields read through the API records the list a price came from so
    price provenance must be captured deliberately, that computed line-item amounts are stale in
    the write response and must be re-read, and that discount fields are readable but not
    writable. The opportunity value rollup from line items could not be made to fire on the API
    path and is recorded as an open question rather than a finding.

**Blueprint 008 — How do you forecast renewals that don't exist as records yet?**
- HTML: https://blueprints.coevera.com/blueprints/forecasting-renewals-before-they-exist/
- Markdown: https://blueprints.coevera.com/blueprints/forecasting-renewals-before-they-exist.md
- Category: Automation · Revised 2026-09-23
- Summary: Renewal and recurring-revenue forecasting in Coevera CRM, built on separating two
    questions that are routinely conflated. What a signed multi-year deal already commits is
    answered by a native revenue schedule on the existing opportunity — startDate, periodCount, a
    periodType of Month, Quarter or Year, a cancelationDate for mid-term churn, and generated
    period records each carrying a date and a value (read from the schema; period generation not
    observed; available on the Business & Enterprise tier per the help centre), which is the
    structure that makes period-based revenue reporting possible. Whether the customer will renew
    is a separate sales question answered by a native opportunity recurrence rule with a required
    target step, an occurrence window and count, and cadences including daily, weekly, monthly and
    yearly in absolute and relative forms plus AfterNDays/Weeks/Months/Years — the last family
    matching a contract term. Also documents why creating renewal opportunities years in advance
    degrades conversion rate, sales cycle, stage ageing and weighted forecast; that opportunity
    types are one-to-one with pipelines; the custom fields renewals always need (term, renewal
    date, permitted uplift, PO requirement, churn risk); that period types cannot express
    irregular billing and, in the opportunity-value mode, only one schedule attaches per
    opportunity (a product-line mode schedules each line item separately); and that opportunity
    value reads as a composite but must be written as a scalar.

**Blueprint 009 — How do you automate on CRM fields that another system owns?**
- HTML: https://blueprints.coevera.com/blueprints/automating-on-integration-owned-fields/
- Markdown: https://blueprints.coevera.com/blueprints/automating-on-integration-owned-fields.md
- Category: Integration · Revised 2026-09-23
- Summary: Most commercially important CRM automation branches on fields the CRM did not produce
    — subscription status, contract start, end and renewal dates, seat counts, spend to date,
    suspension flags — replicated in from a billing or provisioning system. The pattern is to
    treat those fields as evidence rather than as state and split them into three layers: mirrored
    upstream values that are read-only for every role and marked by a naming convention; a small
    set of CRM-owned derived fields, written only by mapping processes, that all downstream
    automation actually branches on; and sync-health fields, a last-sync timestamp and a
    replication-completion flag used as the trigger surface so a process fires once on a coherent
    record rather than mid-write. Each mapping process ends with an unmapped-value branch so a new
    upstream enum value surfaces as an alert instead of silently taking a fall-through path, and
    contradictions the upstream can emit — an end date on an active subscription, a cancelled
    status with no end date, a start date changing on a live contract — are detected and routed to
    a person rather than corrected in the CRM, which does not own them. The limits section
    documents an observed multi-day replication outage in production: change-triggered automation
    is silent rather than failed, since a dead integration is indistinguishable from a quiet week;
    scheduled automation keeps running confidently on stale data and sends customer-facing emails
    computed from wrong numbers; the catch-up burst fires every change-triggered process at once
    with correct field values but the wrong day anchor, so actions that stamp today's date record
    the recovery date rather than the event date; exact-match conditions such as an end date equal
    to yesterday, a tenure of exactly thirteen months, or exactly sixty days to renewal are
    skipped permanently and without trace when the catch-up jumps over them, which is why every
    such condition should be written as a range plus an already-notified marker; a freshness gate
    reading a replicated last-sync field disabled the very check it was protecting; and
    previous-value snapshots used for change diffs are themselves synced, so diffs reported to
    humans can be misleading after a gap. Also covers why process automation here is not
    transactional, cannot be held until a sync completes, and cannot be replayed against a period
    it did not fire in — making a re-runnable derivation process, a sync-freshness monitor
    independent of the synced data, and reconciliation queries written in advance the three things
    to build first.

**Blueprint 010 — How do you hand a won deal over to the team that delivers it?**
- HTML: https://blueprints.coevera.com/blueprints/handover-from-sales-to-delivery/
- Markdown: https://blueprints.coevera.com/blueprints/handover-from-sales-to-delivery.md
- Category: Handover · Revised 2026-09-23
- Summary: Handing a won deal over to the team that delivers it, in Coevera CRM, drawn from a
    production deployment that has run this way for several years. The central decision is to give
    delivery its own pipeline and clone the won opportunity into it, rather than appending
    delivery stages to the sales pipeline: the two have different owners, stages, field sets and
    definitions of done, and keeping one record in two lifecycles corrupts every pipeline metric,
    since a deal closed in one month and delivered months later reports a sales cycle spanning
    both and a weighted forecast that counts committed revenue as still being won. Because an
    opportunity type is one-to-one with a pipeline in Coevera, a second pipeline means a second
    type and two related records rather than one. The clone is conditional on whether the won deal
    actually contains a deliverable, so deals needing no delivery never reach the delivery queue,
    and it sets per-service quantity defaults from the product mix that was sold. A second source
    pipeline gets its own sibling clone process rather than one process with a compound condition,
    which keeps each readable and separately disableable. The go-live date is treated as a single
    field change that fans out into four separate processes: copying the date onto the customer
    account so account-level automation can see it, computing two derived deadlines that branch on
    the type of implementation, notifying the support team with the implementation scope as the
    real handoff out of delivery, and a day-later account-side scheduled process that notifies the
    owner and creates a follow-up task to close the loop back to customer success. Every automatic
    setter has a manual re-runnable twin, because go-live dates move and a process that only fires
    on change cannot be replayed. The limits are stated plainly: a clone is a snapshot and nothing
    reconciles the two copies afterwards, so backfill jobs in both directions are necessary rather
    than optional; the clone triggers on the deal status changing, so if status flips before the
    line items are attached the service-mix branch sees an empty product list and the defaults are
    silently wrong; there is no native convert-to-project operation; and cross-pipeline reporting
    has to be assembled from two record sets rather than read from one.

**Blueprint 011 — How do you keep hundreds of CRM automations maintainable?**
- HTML: https://blueprints.coevera.com/blueprints/keeping-hundreds-of-automations-maintainable/
- Markdown: https://blueprints.coevera.com/blueprints/keeping-hundreds-of-automations-maintainable.md
- Category: Governance · Revised 2026-09-23
- Summary: Keeping a large CRM automation estate maintainable in Coevera CRM, grounded in a
    production deployment carrying 265 processes across seven entities with 113 on a single
    entity. The structural fact everything follows from is the shape of a process: a trigger, then
    exactly one filter node at the root, then actions. A filter may never be a child of an action,
    so a second independent condition cannot be appended to a process that already has one — it
    must be handed off to another process through a trigger-process node, which carries its own
    filter and therefore applies the next condition. The callee may be a manual or a record-change
    process, and manual is the choice that stops it firing on its own; manual means not
    self-firing rather than user-triggered: manual is one of four trigger types alongside record,
    schedule and online form, and a manual process can be both invoked by another process and run
    by a person from a record, so the same process is simultaneously a subroutine in an automated
    chain and a repair tool somebody triggers by hand. This is why 56 of the 113 processes on the
    busiest entity are manual-trigger, and why that figure is evidence of deliberate decomposition
    rather than of an unused utility drawer. The trap it prevents is subtle: a filter is a single
    IF-THEN-ELSE gate whose first matching branch wins, so three independent corrections written
    as three branches of one process leave a record needing all three with only the first applied,
    silently and with no error. A worked case is an account moving from prospect to customer that
    needs the owner alerted about missing primary contact details, a two-letter region
    abbreviation expanded so country reporting does not split into duplicates, and renewal dates
    populated from a twelve or twenty-four month term — three things that can all be true at once
    and therefore three processes. Because each sub-process keeps a permissive root filter it also
    guards itself when a person runs it by hand as a repair tool. Since the process count is
    decided by the engine rather than by the designer, the controllable variable is legibility.
    Processes can be tagged and the process list filtered by tag, owner and status, but its search
    matches names, and the platform reports when a process ran rather than what calls it: a
    bracketed domain prefix makes a flat alphabetical list group itself and makes a search for one
    domain return everything touching it. The estate examined uses about a dozen prefixes, and
    demonstrates the failure mode, since two of them are the singular and plural of the same word
    with twelve processes under one spelling and thirteen under the other. Three decay patterns
    are documented as observed: retired processes are renamed rather than deleted, with five
    carrying not-used or obsolete in their own names and one of those still firing on a daily
    schedule, because renaming is cheap and proving a deletion safe is not; duplicates accumulate
    by year as a fill process is copied each January and the older copy never retired; and
    scheduled jobs collide on the same hour, three of them here, with no ordering guarantee
    between processes touching the same records. The audit that finds all of this from the outside
    is given: group by prefix, check for singular and plural drift, group scheduled processes by
    time, search names for retirement words and personal initials, and trace call chains, since a
    sub-process nothing invokes is the one kind of dead process that can be proven dead.

**Blueprint 012 — How do you run a customer survey from your CRM and get the answers back onto the record?**
- HTML: https://blueprints.coevera.com/blueprints/customer-survey-answers-onto-the-record/
- Markdown: https://blueprints.coevera.com/blueprints/customer-survey-answers-onto-the-record.md
- Category: Feedback · Revised 2026-09-23
- Summary: Customer surveys in Coevera CRM, built on the native online-forms subsystem rather
    than a third-party survey tool. The definition entity is the form type: it names exactly one
    entity type it can attach to, carries the layout, a required style record, a public link, an
    enabled flag, and native counters for sends, responses and response rate. The entity
    confusingly named for the form is the submitted response: it holds the answers, the responder,
    the response date, custom fields of its own, and a relation join to accounts, contacts, leads,
    opportunities, quotes, projects and custom entities with one marked primary. Answers are
    returned as a list of form-field id and string value pairs, so every answer including a rating
    arrives stringly-typed. Fifteen form field types exist (single-line input, text area,
    dropdown, radio, multi-select checkbox, checkbox, rating, date, date-time, email, integer,
    float, phone, file upload, products and services); there is no lookup and no currency field
    type. Every form field maps to a CRM field and carries required, visible, read-only, a
    conditional-visibility filter, and prefill settings that draw either from a record field or a
    custom value — which is the mechanism behind hidden identity fields that carry the surveyed
    record in the link. A rating field is bounded by author-chosen from and to values with anchor
    labels, so a 0-10 net-promoter scale and a 1-5 satisfaction scale are the same field type.
    Three settings decide how a response reaches a record and they are the central design choice:
    link-record when the form was sent from the record and identity comes from the send, autolink
    when the form is published or embedded and one form field must be matched against one record
    field, and create-record when the respondent is new. Writing answers onto the surveyed record
    is declarative: an update template whose target field values are ppl-tag references to form
    field ids with a Responses relation type, alongside built-in tags such as the current date,
    several tags concatenated into one target field, and dropdown targets set by option UUID
    rather than label. Form submission is one of exactly four process trigger types alongside
    record change, schedule and manual; the trigger's entity type is the response, not the
    surveyed record, and a separate record type names what the response attached to, so automation
    runs on the response and reaches the customer record through the relation. One process can be
    bound to several forms at once, and one form usually needs several processes, because a
    process carries exactly one filter whose branches are first-match-wins. The limits are
    load-bearing: the built-in response rate is responses divided by unique recipients, so it is
    blank for any form that was never emailed and exceeds 100% when responses arrive from people
    the form was not sent to, through a forwarded or published link; a form belongs to one entity
    type so a lead-to-opportunity questionnaire is two forms; a public form with autolink and
    record-update both enabled is a write endpoint keyed on whatever identifier the respondent
    supplies; unmatched responses are preserved in an unknown-respondent bucket that nothing works
    automatically; answers are strings so anything to be reported on must be written to a typed
    field; a response outlives the record it points at and both response and summary carry an
    availability flag for that case; and the platform's summarised response value is
    schema-visible but was not populated on any form in the estate examined, so a survey score has
    to be computed into a field of your own.

**Blueprint 013 — How do you add a contact form to your website that writes straight into your CRM?**
- HTML: https://blueprints.coevera.com/blueprints/website-contact-form-into-crm/
- Markdown: https://blueprints.coevera.com/blueprints/website-contact-form-into-crm.md
- Category: Lead capture · Revised 2026-09-23
- Summary: Building a website contact form — the public form behind a Contact us, Apply now or
    Request a call button — so that submissions become CRM records directly, verified against a
    live partner-programme application form in production. The CRM hosts the form: each form
    definition carries a link id and the public form is served from a URL built out of that id, so
    the website stores only that URL plus an accessible title and holds no form markup, no field
    names, no submission endpoint and no API key — which is what lets an administrator change the
    questions without a website deployment. The hosted form is a JavaScript application served
    from a static CDN and the response carries no frame-ancestors or X-Frame-Options restriction,
    so it embeds in any page; embedded in an iframe, as here, the consequences are that its
    content is not crawlable, a visitor without JavaScript sees nothing, and the parent page's
    analytics and consent tooling cannot observe anything inside the frame, including abandonment.
    Deduplication is the central configuration: enabling create-record, update-record and autolink
    together turns a submission into an upsert, where autolink names one form field and one record
    field and an unmatched submission is the only one that creates a record — observed reducing 49
    submissions to 41 distinct people with zero unmatched responses. The creation template is a
    complete record payload rather than a patch: it enumerates every standard field including all
    five phone and five email slots, carries a contact sub-type id so programme applicants are
    distinguishable at record level, and carries fixed owner and sales-unit ids because every
    record requires both and an anonymous visitor supplies neither, which makes assignment to a
    real person a separate routing concern. Provenance is stamped twice, once as a free-text
    comment and once as a source field, and the two drift apart because the free text is typed by
    hand. A required privacy checkbox can be absent from the creation template, in which case
    consent is captured but not queryable — it survives only on the response record and its
    attached PDF. Notification should be addressed to the form owner rather than the primary
    record owner, since the created record's owner is a nominated placeholder. Automation binds to
    the specific form, runs on the response record with the created contact named as its record
    type, and was observed firing about eight seconds after submission; because the confirmation
    page promises an email, sending that email is a contract the automation has to honour. The
    limits are structural: an embedded form has a send count of zero, so it has neither a response
    rate nor a sent-and-not-responded list, and the chase for people who started but never
    finished has to be rebuilt as a scheduled process over the created records; leaving repeat
    responses unrestricted is correct for an upsert form and destroys the metric on a sent one; an
    upsert keyed on an email address is a write path keyed on a guessable identifier; nine
    required fields on a public form is a conversion cost that cannot be measured from outside the
    frame; and form field definitions are shared space-wide, with identical field identifiers
    observed on two unrelated forms in the same space.

**Blueprint 014 — How do you spot customers at risk of churning before renewal?**
- HTML: https://blueprints.coevera.com/blueprints/customer-health-score-churn-risk/
- Markdown: https://blueprints.coevera.com/blueprints/customer-health-score-churn-risk.md
- Category: Customer success · Revised 2026-09-23
- Summary: Customer health and churn-risk scoring in Coevera CRM, built on the native
    entity-health engine rather than a hand-maintained score field. A health configuration exists
    per entity type and per record sub-type — in one live space fifteen of them on Account, one
    per account type, with exactly one enabled — so bands and indicators are not global and the
    same score can read differently under two sub-types. Each configuration holds four things: the
    category bands, each with a label, an integer threshold and a colour; a calculation type of
    either Manual, where each indicator rule carries its own point score and the scores sum, or
    Priority, where the rules are ordered and carry zero points; a set of health indicators; and a
    separate set of critical indicators. An indicator rule is a field id, an operator drawn from a
    vocabulary of twenty-three including Is, IsNot, Less, More, Between, Contains, RelativePeriod
    and IsEmpty, a value list, a point score, and a description field intended to explain the rule
    in words. Critical indicator rules carry a score of minus one, and because every configuration
    also defines a Critical band at minus one, a single matched critical indicator should force
    the worst band regardless of how well the weighted rules scored — inferred from those stored
    values, not observed in a recalculation. Per record the engine exposes a readonly integer
    health status, a writable health category id, and a health result object carrying score, trend
    of Increasing, Decreasing, NoChange or Critical, the per-indicator evaluation of Ok, Error or
    Critical with the date each last changed, and a last-calculation timestamp; a health analysis
    object adds day-by-day history where each entry records the score, the trend and the
    individual changes with a score difference, rule id and field id, which is what lets a drop be
    attributed to the rule that caused it. Good indicators are operational signals the customer
    generates rather than opinions someone records — licence utilisation, the last telemetry sync
    date, the date the customer last created a record, a rollup of support tickets older than two
    weeks, account status and a sent-to-collections flag are a working live set covering usage,
    connectivity, support strain and commercial standing. The health category is a verified
    process trigger surface: a production process watches that single field for change and emails
    the relationship owner. The central design rule is that it should stop there, because a score
    is a probabilistic signal and customer outreach is a commitment: the health change notifies a
    person, the person records a verdict in a dedicated field, and the verdict field change is
    what triggers the outreach chain, which then fans out through sub-process handoffs. The limits
    are load-bearing: the score is recalculated rather than live, so automation fires when
    recalculation runs and not when the underlying field changed; the per-rule description field
    was empty on every rule in every configuration examined, leaving the score unable to explain
    itself without resolving field identifiers by hand; an indicator built on a field a separate
    system replicates turns an integration outage into a fleet-wide fake churn signal; the health
    category is writable, so a human override is indistinguishable from a computed value; a
    boolean condition is stored with a null operator and the value carries the sense, "1" for true
    and "0" for false, so the operator cannot be read without the value; the related-entity
    indicator capability is schema-present but was unused; and only Account was observed carrying
    a health configuration despite the schema admitting other entity types.

**Blueprint 015 — How do you handle volume discounts that differ by region and by product?**
- HTML: https://blueprints.coevera.com/blueprints/volume-discounts-by-region-and-product/
- Markdown: https://blueprints.coevera.com/blueprints/volume-discounts-by-region-and-product.md
- Category: Pricing · Revised 2026-09-23
- Summary: Volume and quantity-break pricing in Coevera CRM, verified against a live
    1,637-product distributor catalogue priced for two regions. The governing constraint is that a
    price-list row holds exactly one price for one product in one currency — its entire settings
    object is an access enum plus an optional role list — so there is no native quantity break, no
    minimum-quantity field and no tier structure anywhere in the price list. Which lists are on
    offer, by contrast, is highly configurable: any number of price lists can be valid at the same
    time, and each carries a rules field filter — labelled price-list availability in the
    interface — with an enabled flag, a group operator, a main filter box and sibling boxes,
    testing any field on the quote, the opportunity or the account. Those three entities are the
    whole scope. Critically the rule governs availability rather than application: it decides
    which lists appear in the price-list dropdown on the Products & Services panel, the dropdown
    defaults to "Without price list", and a person still chooses — no rule applies a list on its
    own. Until a list is chosen every line is added at a price of zero, which makes the commonest
    pricing failure a default rather than an edge case; once one is chosen new lines take its
    price, and the interface asks whether lines already on the record should be re-priced. The
    chosen list is recorded on the quote in a native price-list relation. Region is simply the
    field one worked example filtered on. The one dimension no rule can test is quantity, because
    quantity is a property of the line item rather than of any record the filter evaluates. The
    panel itself exists on Opportunity and Quote only. Price lists also carry a type of Standard
    or Scheduled, a status of Active, Inactive, Scheduled or Expired, start and end dates, and a
    default flag; the shipped default list arrives inactive. Creating a separate price list per
    quantity tier therefore does not work, and lists would in any case multiply by every other
    selection dimension times band. The working model puts the break schedule on the product as
    integer discount-percentage fields, one per band per region, and marks region-specific
    quote-only products with a price-on-request checkbox rather than a price row; percentages
    rather than absolute tier prices are what let a repricing be a single price-list import
    instead of a rebuild of every tier. Because each band is a field, band boundaries live in the
    schema: a catalogue arriving with five bands in one region and three in the other must be
    normalised to the common bands, and changing them later is a schema change plus a data
    migration. Three distinct per-region concepts have to be modelled separately — whether a
    product is available in a region, whether it has a price there, and whether it is deliberately
    quote-only — since a missing price row is indistinguishable from an unconfigured one and a
    zero price silently produces a zero-value quote. The arithmetic reconciles: 1,637 products,
    788 price rows in one region and 1,193 in the other, with 370 and 339 quote-only listings
    carrying flags instead of prices. The remaining step is the band calculation itself, which was
    modelled but not automated in the space examined: bands are mutually exclusive, so unlike most
    automation in this platform a single filter with ordered branches is the correct shape,
    reading the line quantity, selecting the band field matching the quote's region, and writing
    the discount percentage or net unit price onto the line item.

**Blueprint 016 — How do you chain email sequences so that what a prospect does decides what happens next?**
- HTML: https://blueprints.coevera.com/blueprints/chaining-email-sequences-on-engagement/
- Markdown: https://blueprints.coevera.com/blueprints/chaining-email-sequences-on-engagement.md
- Category: Outreach · Revised 2026-09-23
- Summary: Chaining email sequences on recipient behaviour in Coevera CRM. An email sequence is
    a closed loop: its trigger names an entity and the specific email field to enrol on,
    optionally across a lookup; its nodes send steps on a day offset and can create records; and
    it ends. There is no node that enrols a record into another sequence, so a multi-stage ladder
    has to be assembled from three parts. First, global actions, which are the sequence's
    behavioural hooks and come in exactly four events — on reply, on unsubscribe, on a custom
    condition, and on bounce — each with its own combination of unenrol, send-a-different-email
    and create-a-record-from-a-template flags; the custom condition is the only one that takes a
    filter, and is how an open or a click is caught, typically by testing the message subject
    together with an email tracking status of opened or clicked. Bounce additionally offers to
    unsubscribe the recipient, which makes a bad imported list burn itself down on first contact.
    Second, the record the global action creates carries the routing payload: a field on that task
    names the sequence to enter next, which makes the ladder a hard-coded chain of pointers rather
    than an incrementing counter. Third, a catcher process triggered on task creation reads the
    pointer onto the contact and hands off to the enrolment process. That catcher must set its
    trigger actor to applications only — one of four values alongside process owner, selected
    units and users, and any user — or a task created by a person silently re-enrols somebody. The
    limits are the substance: a ladder whose task templates are created already completed, owned
    by one administrator and consumed only by automation generates activity records and no work
    items, so a cohort can sit parked at the first step for months with nothing reporting it; a
    pointer field whose label describes a duration rather than a destination is load-bearing and
    silently reroutes anyone who edits it; a final sequence that terminates only because its
    create-task flag is switched off, while its template still carries a pointer back to an
    earlier step, is one checkbox away from an infinite loop; nothing advances the step counter
    except the catcher, so a contact whose engagement never fires stays at step one permanently;
    an enrolment process shared by dozens of unrelated campaigns is a single first-match-wins
    ladder where a branch's reachability depends on its position; and a chain that stops receiving
    new records at the front produces silence rather than errors. Per-sequence statistics are
    extensive — enrolments, sends, recipients, opens, clicks, replies, bounces, unsubscribes,
    created tasks and leads, and a current-enrolment count — but they are per sequence, so the
    health of the ladder as a whole is not reported anywhere and has to be assembled.

Further blueprints will be listed here with canonical HTML URLs and a plain-Markdown
twin at the same path with a `.md` suffix.

## Other languages

- [Deutsch](https://blueprints.coevera.com/de/llms.txt): https://blueprints.coevera.com/de/
- [Español](https://blueprints.coevera.com/es/llms.txt): https://blueprints.coevera.com/es/
- [Italiano](https://blueprints.coevera.com/it/llms.txt): https://blueprints.coevera.com/it/