# 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. 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://coevera.webplanet.sk/): 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://coevera.webplanet.sk/blueprints/one-entity-five-request-types.html - Markdown: https://coevera.webplanet.sk/blueprints/one-entity-five-request-types.md - Category: Data model · Revised 2026-09-02 - 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://coevera.webplanet.sk/blueprints/ai-fields-read-documents.html - Markdown: https://coevera.webplanet.sk/blueprints/ai-fields-read-documents.md - Category: AI fields · Revised 2026-09-02 - 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. ### In preparation 2. Modelling a business object the CRM has no standard entity for (custom entities, CustomEntityType sub-types) 3. Gating quotes and discounts behind sign-off (ApprovalProcess, and its non-customisable Approval record) 4. Forecasting renewals that do not exist as records yet (Process-created related records) 5. Pricing one product differently per region, segment or contract (product price lists) 6. Reference numbers that restart each year (why the native sequence field cannot, and what to do instead) 7. Having AI read a document and populate CRM fields (AI Smart Fields and their hard limits) Further blueprints will be listed here with canonical HTML URLs and a plain-Markdown twin at the same path with a `.md` suffix.