Features
StableBetaComing soon
activity-timeline@e2e exclude backend service — activity entries are created by PHP event listeners and stored as OR objects; covered by PHPUnitAdmin SettingsThe admin settings page provides a Nextcloud admin panel for configuring Pipelinq. Administrators can manage pipelines and their stages, set a default pipeline, configure lead source and request channel values, manage product categories, and configure prospect discovery (ICP) settings. Only Nextcloud admin users can access the admin settings page; regular users access per-user notification preferences via an in-app settings dialog. The design follows the wireframe in DESIGN-REFERENCES.md section 3.7.Spec: Admin Settings — Duplicate PreventionPrevent administrators from creating duplicate tag values in the `TagManager` component used on the admin settings page (lead sources and request channels). Duplicate detection is case-insensitive and runs client-side before any emit. A clear error message is displayed when a duplicate is detected; no data is submitted.appointment-bookingProvides end-to-end appointment booking with services, resources, and availability computation, plus a public self-service portal where customers book, reschedule, and cancel without logging in. Handles deposits, reminders, no-show tracking, walk-in queues, and bi-directional calendar sync, with confirmation emails, AVG-compliant retention, and admin management of services and bookings.avg-verzoeken-workflowDefines the handling of AVG (GDPR) data-subject requests — classification, 30-day deadline tracking, extensions, federated evidence collection, redaction, signed export bundles, denials, AP escalation, and retention. Every requirement is a handoff: pipelinq itself does not implement these workflows but delegates them to the canonical owners (docudesk, the AVG dossier capability, and rekenkamer-audit-pack), documenting the integration contracts those owners must satisfy.Delta Spec: callback-managementManage callback requests (terugbelverzoeken), follow-up tasks (opvolgtaken), and information requests (informatievragen) in Pipelinq via a `task` schema mapped to VNG `InterneTaak` and Schema.org `Action`. The capability lets agents register, assign, schedule, and track these tasks through to completion.Client ManagementClient management is the core capability of Pipelinq. A client represents a person or organization that the team has a relationship with. Contact persons are individuals linked to organization clients, qualified by role. This specification covers client and contact person CRUD, list views with search/sort/filter, the client detail view (info panel, summary stats, contact persons, leads, requests, activity timeline), validation rules, Nextcloud Contacts sync, and future capabilities such as duplicate detection and import/export.commercial-dashboardProvides a commercial overview dashboard as the default landing page, showing revenue, won value, win rate, average deal size, weighted forecast, and open pipeline value alongside trend charts and closing-soon/recently-won deal tables. Backed by an authenticated analytics endpoint and a seeded demo dataset, it splits commercial KPIs from the operational widgets, which move to a dedicated Operational overview.Contact Relationship Mapping@e2e exclude backend data model — contact relationship entity and inverse-link logic are OR-object CRUD; covered by PHPUnitContactmomenten Rapportage@e2e exclude draft/unbuilt spec — rapportage analytics dashboard not yet implemented; no UI surface to testContacts Sync@e2e exclude backend integration — vCard sync via Nextcloud IManager is a PHP service; covered by PHPUnitcrm-workflow-automation@e2e exclude draft/unbuilt spec — n8n workflow automation UI bridge not yet implemented; no UI surface to testcti-screenpop-adapterIntegrates pipelinq with telephony platforms so inbound calls screen-pop the caller's CRM record and phone fields offer one-click click-to-dial. Every call creates a contactmoment with disposition workflow, recording metadata, and agent presence sync, via a pluggable per-platform adapter (CallVoip, RingCentral, Asterisk) with verified webhooks, plus admin configuration and an event log.DashboardThe Pipelinq CRM dashboard provides an at-a-glance overview of key performance indicators, pipeline health, assigned work, and client activity. It uses the `CnDashboardPage` component from `@conduction/nextcloud-vue` for a configurable grid layout and integrates with the Nextcloud Dashboard Widget API (`OCP\Dashboard\IWidget`) for platform-level widget exposure.docs-product-pages-conformanceBring the Pipelinq documentation site into conformance with the `@conduction/docusaurus-preset` product-pages standard: a canonical folder taxonomy, an installation guide, a Redocusaurus `/api` mount, an `nl` locale, and consistent typography. Conformance is a docs-site structure concern verified by CI file-tree checks, not a Nextcloud app UI.email-calendar-sync@e2e exclude draft/unbuilt spec — email and calendar sync integration not yet implemented; no UI surface to testEntity Notes@e2e exclude backend integration — notes use Nextcloud ICommentsManager; entity detail tabs unbuilt as standalone UI surface; covered by PHPUnitKCC Werkplek@e2e exclude draft/unbuilt spec — KCC werkplek unified agent screen not yet implemented; no UI surface to testKlachtenregistratie (Complaint Registration) — Delta Spec@e2e exclude backend delta spec — complaint schema and SLA logic are OR-object CRUD and PHP service; covered by PHPUnitLead ManagementLead management handles sales opportunities -- from first contact through to won or lost. A lead is a unified entity (no separate Opportunity split) that flows through configurable pipeline stages. Pipeline stages encode qualification level, making a separate conversion step unnecessary.Lead-Product Link@e2e exclude backend data model — lead-product line items are OR-object CRUD; product-attachment UI not yet exposed as a testable standalone surface; covered by PHPUnitmarketing-analyticsProvides a marketing performance dashboard that reports per-blast delivery metrics, A/B click-rate significance via a chi-square test, and revenue attribution. It surfaces an overview table of recent blasts (open/click rates, unsubscribes), an A/B testing tab with statistical significance once each arm reaches sufficient volume, and an attribution tab summing attributed deal value per blast.marketing-apiExposes the REST API for marketing blasts, segments, and campaign templates with standard CRUD, pagination, and filtering. It derives user identity from the server session rather than trusting the request body, validates segment rule trees and template compliance before saving, and returns generic error messages that do not leak internal details.marketing-blastSends marketing email blasts to contact segments, dispatching through openconnector's per-tenant send-mail provider so provider credentials never live in pipelinq code. It supports deterministic A/B splitting (each contact always gets the same variant), respects per-source rate limits, and creates revenue attribution links that join blasts to closed deals with first-click timestamps and attributed value.marketing-blast-deliveryDrives blast delivery via a background job that dispatches queued sends every few minutes and processes provider webhooks without one blast's failure aborting the others. It propagates unsubscribes to consent records within a minute, handles hard and soft bounces to protect sender reputation, and records click events (first-click time, clicked URLs, UTM campaign) for attribution.marketing-complianceEnforces lawful-basis consent and anti-spam rules before a marketing blast can be sent. Blocks sends to contacts that lack a consent record for the target channel, requires an unsubscribe token and physical-address block on email templates, and propagates consent withdrawals from unsubscribes and hard bounces so queued deliveries are skipped.marketing-docsDocuments the marketing blast feature in the CHANGELOG and a user guide. The user guide covers creating segments and compliant templates, scheduling and sending blasts, A/B testing, and monitoring delivery and revenue attribution, and is available in Dutch and English.marketing-segmentationProvides rule-based audience segments for marketing blasts, composed from AND/OR rule trees whose leaf predicates are validated against the entity schema before save. Segments are evaluated dynamically at send time rather than frozen as static lists, so newly matching contacts are auto-included and deleted contacts drop out, and the register seeds realistic Dutch example data across the six marketing schemas.marketing-testingDefines the test coverage for the marketing blast services. PHPUnit unit tests cover rule validation and evaluation, consent gating, template validation and withdrawal, and send, dispatch, A/B, and throttle behaviour, and an end-to-end integration test exercises segment creation through blast send using the real ObjectService.marketing-uiProvides the marketing blast user interface: a SegmentBuilder for visually composing AND/OR rule trees with live validation and member-size estimates, a BlastForm wizard that walks the marketer through name, segment, template, channel, schedule, and A/B and gates sending on compliance, and a BlastMonitor that polls for real-time send progress, totals, and events and can cancel a sending blast.marketing-verificationDefines the end-to-end verification and pre-merge checklist for the marketing blast feature. Requires the unit and integration suites to pass with at least 80% service coverage, the full draft-to-sent send workflow, compliance blocking, A/B, and unsubscribe behaviour to be verified, and a security checklist confirming pattern invariants such as ObjectService-only CRUD, consent gating on every send, and template enforcement.master-data-managementMaintains a single authoritative golden record per master entity by resolving conflicting attribute values through configurable per-source trust tiers, detecting deterministic and probabilistic duplicates, and providing reversible merge tooling with preview. Computes a data-quality score, records an audit trail of merges and gold-record mutations, executes AVG right-of-deletion, and publishes golden records to downstream apps via a read API and a retrying sync queue.My Work (Werkvoorraad)My Work provides a personal workload view aggregating all items assigned to the current user -- leads, requests, and optionally tasks from Procest. This is the user's daily productivity hub, showing what needs immediate attention, what is due soon, and what is upcoming. Items are organized into temporal groups (Overdue, Due This Week, Upcoming, No Due Date) and sorted by priority within each group.Notifications & Activity Stream@e2e exclude backend notification engine — dispatch logic and OR activity stream events are PHP services; covered by PHPUnitOmnichannel Registratie@e2e exclude draft/partial spec — channel-specific metadata form adaptations not yet built as separate UI surface; covered by contactmomenten UI testsOpenRegister Integration@e2e exclude backend integration foundation — register schema init, Pinia store wiring, and OR API CRUD are PHP/JS infrastructure; covered by PHPUnit and unit testsPipeline & KanbanPipelines provide configurable kanban-style boards where leads and requests flow through ordered stages. A pipeline is comparable to Trello boards or Nextcloud Deck -- each pipeline has columns (stages) and cards (leads/requests). Both entity types can appear on the same pipeline, distinguished by visual badges. Pipelines are the primary visual workflow tool in Pipelinq.Pipeline InsightsAdd temporal, financial, and analytical context to pipeline views so users can spot bottlenecks, prioritize overdue items, forecast revenue, and see conversion metrics at a glance. This spec covers both the real-time visual indicators on pipeline views and the analytical dashboard components for pipeline performance tracking.Pipelinq OpenRegister-AdoptionTrack the cross-cutting work that aligns pipelinq with the shared OpenRegister abstractions and multi-tenant deployment model. This slice covers Phase 7 (admin-config) and Phase 8 (manifest adoption). Phase 7 moves hardcoded constants (background-job timing, business hours, third-party API base URLs, cache TTL, default review intervals) into admin-config so they are tunable per deployment without code changes, while preserving current behavior for any install that leaves them unconfigured. Phase 8 ships the OpenSpec coordination manifest (`openspec/manifest.yaml`) declaring pipelinq's tier, OpenRegister dependency, the shared specs it consumes, the minimum OR version, and its object-store-exemplar role. The Phase 9 multi-tenancy + i18n runtime-adoption consumes are declared in the manifest; their runtime adoption is deferred until the nc-vue / OpenRegister prerequisites ship.pipelinq-pos-groupingOrganizes the point-of-sale and product navigation into coherent groups without changing any routes. Groups the till runtime leaves under a single "Point of Sale" entry, places product master data under a separate "Catalog" group, moves POS staff and role configuration into the Settings foldout, and keeps the pages array unchanged so every affected deep link still resolves.POS Barcode Scan (HID + camera)Define the requirements for barcode input capture and product lookup in the pipelinq POS context. This spec covers HID keyboard-wedge detection, BarcodeDetector API camera scanning, product resolution (including variant-level), and error handling. The implementation provides a composable scanning layer (`useBarcodeScanner`, `useBarcodeProductLookup`) and a unified `BarcodeScanner.vue` component.POS Lifecycle Guard AdoptionMove the POS transaction and refund lifecycles onto OpenRegister's declarative `x-openregister-lifecycle` machinery: route every state transition through `TransitionEngine`, enforce per-object authorization in `LifecycleGuardInterface` guards (closing the confirmed IDOR), and recompute totals server-side — removing the bespoke PHP state machines and the hand-rolled `isManager` check.POS NL BTW EngineProvide a server-side Dutch BTW (VAT) computation engine on top of pos-transaction-core: per-rate `taxBreakdown`/`invoiceBreakdown` (GL split with Dutch descriptions) for shillinq, end-to-end tax-inclusive vs tax-exclusive computation (`priceMode`, not display-only), a `GET /api/pos-transactions/tax-report` compliance endpoint, and a CloudEvent payload shillinq consumes for its general ledger.POS Product CatalogueExtend the existing `product` schema into a POS-grade product master (variants matrix, modifier groups, quantity price tiers, explicit Dutch BTW class, barcode/EAN, service duration) backed by a server-authoritative ProductCatalogService and Controller. These additions make the catalog usable as a POS product master for Shillinq and retail/salon POS integrations while preserving backward compatibility with the existing flat CRM product fields.Spec: POS Receipt EngineEnable printing and emailing of receipts from POS transactions to thermal printers and customer email addresses. Receipts are generated from customizable templates with optional legal invoice mode for Dutch VAT compliance on high-value transactions (≥ EUR 100).POS Transaction CoreProvide the core POS transaction model for Pipelinq: two OpenRegister schemas (`posTransaction` with the draft→parked→confirmed→settled→refunded lifecycle, per-rate tax breakdown and grand total; `posTransactionLine` with qty/discount/computed tax), a server-authoritative PosTransactionService (totals, lifecycle, CloudEvent to shillinq) and PosTransactionController, plus Vue list/detail/cart views.Product Catalog@e2e exclude backend data model — product and category CRUD are OR-object operations; product CRUD UI is a future V1 surface not yet built; covered by PHPUnitproduct-catalog-quoting@e2e exclude draft/unbuilt spec — quote generation and PDF export not yet implemented; no UI surface to testProduct & Service Catalog (PDC)@e2e exclude backend API spec — PDC public read-only API, UPL conformance, and zaaktype linking are backend/API concerns; covered by Newman and PHPUnitPrometheus Metrics Endpoint@e2e exclude backend API endpoint — Prometheus metrics and health check are HTTP API concerns; no UI surface; covered by NewmanProspect Discovery@e2e exclude backend API integration — KVK/OpenCorporates registry search and ICP scoring are PHP service calls; covered by PHPUnit and Newmanpublic-intake-forms@e2e exclude draft/unbuilt spec — embeddable intake forms not yet implemented; no UI surface to testQueue Management@e2e exclude backend data model — queue entity CRUD and routing logic are OR-object/PHP service; covered by PHPUnitRegister Content Internationalization@e2e exclude backend i18n infrastructure — translatable field storage, language fallback chain, and IL10N wiring are PHP/OR-object concerns; covered by PHPUnitSpec: Locale-Aware FormattingReplace all hardcoded `nl-NL` locale formatting calls across Vue components with a shared `localeUtils.js` utility that respects the active Nextcloud user locale. Monetary values and dates must render correctly for any locale configured in the user's Nextcloud profile.Request ManagementRequest management handles the intake and tracking of requests (verzoeken) — service inquiries that come in before they become formal cases. Requests are the bridge between Pipelinq (CRM) and Procest (case management). A request flows through a status lifecycle from intake to resolution or conversion, can optionally be placed on a pipeline alongside leads, and can be converted into a Procest case.Skill-Based Routing@e2e exclude backend routing engine — skill matching and advisory routing logic are PHP service operations; covered by PHPUnitsla-engine-and-escalationResolves an immutable SLA policy per tracked object at creation, computes holiday-aware and business-hours deadlines, and pauses and resumes timers on status changes. Drives an idempotent escalation chain across email, notification, WhatsApp, and webhook channels as deadlines are consumed, reconciles silent deadline crossings through a scheduled sweep job, exposes attainment reporting, and records an audited, justification-gated history of policy changes, integrating with OpenRegister object events rather than polling.task-background-jobsRun the periodic background jobs that keep task state current without user interaction: a TimedJob that expires tasks past their deadline (status → "verlopen") and deadline-escalation notifications. These run in PHP cron with no UI surface and are covered by PHPUnit.Time Approval WorkflowThe timesheet submit → approve → reject → lock → edit-request → invoice lifecycle is **delegated to shillinq**, not built in Pipelinq. The time-tracker leaf (`integration-time-tracker`) explicitly excludes approval + invoicing, and **hydra ADR-022** forbids an app building a parallel mechanism for a capability owned elsewhere in the fleet. Approval is the gate before billing, so it lives with billing in shillinq (see shillinq `invoice-from-time-and-expense`, `rate-card-management`, `wbso-uren-tagging-and-export`). Pipelinq captures hours via the leaf, links them to its objects via OpenRegister integration link tables, and surfaces a deep-link to shillinq's billing/approval surface.Time Entry CorePipelinq needs hour capture against clients, leads, projects and requests so that downstream billing (shillinq) and profitability analysis are possible. Per **hydra ADR-022** (apps consume OpenRegister abstractions over local duplication), Pipelinq **consumes** the OpenRegister **time-tracker leaf** (`integration-time-tracker`) for capture rather than building a bespoke time subsystem. The leaf provides hour capture as a reusable integration: `TimeProvider` + `TimeTrackerLinks{Controller,Service,Mapper}` (PHP, in OpenRegister) and `CnTimeTrackerTab` (quick-log form, entries grouped by user/date, total hours) + `CnTimeTrackerCard` widget (nextcloud-vue). The leaf is gated on the NC `timemanager` app and stores entries in an OR link table (`time entries linked to object/user`).time-entry-mobileProvides a mobile, installable PWA timer that captures hours offline and submits them to the OpenRegister time-tracker leaf rather than a Pipelinq schema. The mobile-specific layer is limited to a PWA shell, an IndexedDB offline buffer, and a sync queue that idempotently flushes buffered captures to the leaf on reconnect, renders responsively with touch-sized controls, and attaches optional GPS as leaf capture metadata.unify-client-contactKeys the `client` and `contact` records to a Nextcloud Contact via a required `contactsUid`, demoting their identity fields to denormalised read-only mirrors while keeping CRM and governance fields authoritative, and links `contactmoment` interactions to the party by `contactsUid`. Refreshes the mirrors through the existing contact-sync flow with the Nextcloud Contact as the source of truth, and provides an idempotent, non-destructive repair that resolves or creates contacts and re-keys existing objects while preserving all three people-surface nav entries and routes.