Case management for Nextcloud — configurable workflows, deadlines, and formal decisions
Dossiq brings structured case management (zaakgericht werken) natively into Nextcloud. Define case types with custom status lifecycles, track progress and deadlines, assign roles, and record formal decisions — all within a clean, intuitive interface that integrates naturally with the rest of your Nextcloud workspace.
It pairs with Pipelinq to form a complete intake-to-resolution workflow: Pipelinq handles the customer-facing CRM side, Dossiq handles the internal case processing.
Requires: OpenRegister — all data is stored as OpenRegister objects (no own database tables).
 |
 |
 |
| Dashboard | Cases | Admin — Case Types |
- Configurable Workflows — Define case types with allowed statuses, deadline durations, required documents, and custom properties
- Status Lifecycle — Design the exact sequence of statuses a case must pass through
- Default Values — Set default confidentiality level, assigned roles, and SLA targets per case type
- Admin Panel — Manage all case types from a dedicated admin settings view
- Case Lifecycle — Full CRUD with status transitions, validation rules, and audit trail
- Status Timeline — Visual progress indicator showing all lifecycle phases and current position
- Automatic Deadlines — Deadlines calculated from case type duration with live countdown (days remaining / overdue alerts)
- Quick Status Changes — Change status directly from the case list without opening the full detail view
- Task Assignment — Create and assign tasks to team members with BPMN-style lifecycle (available → active → completed)
- Formal Decisions — Record official decisions (besluiten) with outcomes, motivation, and effective dates
- Document Checklists — Track required documents at each status stage with upload verification
- Participant Roles — Assign the right people to the right roles: handler, advisor, decision-maker
- My Work Dashboard — Personal overview of all assigned cases, pending tasks, and overdue items
- KPI Cards — At-a-glance counts of open cases, overdue deadlines, pending tasks, and recent activity
- Activity Timeline — Complete history of every change made to a case, with timestamps and responsible party
- Unified Search — Cases and tasks appear in Nextcloud's global search, provided centrally via OpenRegister (dossiq ships no own search provider)
- Pipelinq Bridge — Receive requests handed off from Pipelinq CRM as new cases, via OpenRegister's semantic object handoff (dossiq implements the
ns#Casekind; requests map onto cases with navigable provenance) - Sub-cases — Break complex cases into parent-child hierarchies for structured processing
graph TD
A[Vue 2 Frontend] -->|REST API| B[OpenRegister API]
B --> C[(PostgreSQL JSON store)]
A --> D[Nextcloud Activity]
A --> E[Nextcloud Search]
F[Pipelinq] -->|request handoff| A
| Object | Description | CMMN 1.1 | ZGW Mapping |
|---|---|---|---|
| Case | Formal process with lifecycle | CasePlanModel |
Zaak |
| Case Type | Configurable case template | CaseDefinition |
ZaakType |
| Task | Work item within a case | HumanTask |
— |
| Status | Lifecycle phase | Milestone |
Status |
| Role | Participant relationship | — | Rol |
| Result | Case outcome | — | Resultaat |
| Decision | Formal decision | — | Besluit |
Data standard: CMMN 1.1 (OMG Case Management Model and Notation) with Schema.org mapping and ZGW API compatibility.
dossiq/
├── appinfo/ # Nextcloud app manifest, routes, navigation
├── lib/ # PHP backend — controllers, services
├── src/ # Vue 2 frontend — components, Pinia stores, views
│ ├── components/ # Reusable UI components
│ ├── store/ # Pinia stores per entity (cases, caseTypes, tasks…)
│ └── views/ # Route-level views
├── docs/
│ ├── Features/ # Per-feature documentation
│ └── Technical/ # Architecture and development guides
├── img/ # App icons and screenshots
├── l10n/ # Translations (en, nl)
└── docusaurus/ # Product documentation site (conduction.nl)
The kcc-werkplek-zaaksysteem-bridge capability surfaces real-time zaaksysteem
context inside the pipelinq KCC-werkplek. Pipelinq owns the contact-center UI;
Dossiq exposes a read/write API plus background jobs.
Schemas (modular lib/Settings/register.d/40-kcc-werkplek.json, ADR-037 — the
monolith is never edited): contactmoment, kccQuickAction, belplan,
specialistBeschikbaarheid, doorverbinding, klantSentiment. A burger is a
Nextcloud contact entity resolved through OCP\Contacts\IManager; no bespoke
person/customer schema is introduced.
Services: ContactMomentService (log contacts, append immutable case
activity), BurgerIdentificationService (DigiD pseudonymisation + weighted
identificatievragen scoring), CaseVoorbladService (open zaken + history +
suggested topic), BelplanRoutingService (vaardigheid match + wachtrij-overflow),
QuickActionService (status / nieuwe zaak / klacht / bel-terug),
DoorverbindingService (immutable context snapshot + accept/reject),
SentimentService (Dutch trigger-word + escalatie scoring).
Controllers / routes (under /api/ and /api/kcc/): ContactMomentController,
BelplanController (belplan CRUD is admin-gated), SpecialistBeschikbaarheidController
(read-only).
Background jobs: SentimentAnalysisJob (every 10 min, scores transcriptions),
SpecialistBeschikbaarheidRefreshJob (every 30 s, ages out stale availability).
| Setting | Default | Purpose |
|---|---|---|
identification_method |
both |
digid / bsn_questions / both |
identification_score_threshold |
0.8 |
minimum identificatievragen score to link a burger |
sentiment_polling_interval |
5 |
seconds |
specialist_availability_polling_interval |
30 |
seconds (drives the refresh job staleness window) |
max_zaken_voorblad |
10 |
open zaken shown on the voorblad |
max_contactmomenten_history |
5 |
recent contactmomenten shown |
sentiment_trigger_words |
JSON list | Dutch escalation trigger words |
Troubleshooting — specialist-beschikbaarheid API unreachable? The refresh
job logs a warning and keeps the existing (stale) cache; routing keeps using the
last known availability, and stale records are marked afwezig after
specialist_availability_polling_interval × 4 so calls are never routed to a
silent specialist.
| Dependency | Version |
|---|---|
| Nextcloud | 28 – 34 |
| PHP | 8.3+ |
| OpenRegister | latest |
- Go to Apps in your Nextcloud instance
- Search for Dossiq
- Click Download and enable
OpenRegister must be installed first. Install OpenRegister →
cd /var/www/html/custom_apps
git clone https://github.com/ConductionNL/dossiq.git
cd dossiq
npm install
npm run build
php occ app:enable dossiqdocker compose -f openregister/docker-compose.yml up -dcd dossiq
npm install
npm run dev # Watch mode
npm run build # Production build# PHP — unified strict gate (runs in CI on every PR)
composer check:strict # lint + phpcs + phpmd + psalm + phpstan + tests
# Individual tools
composer phpcs # Check coding standards
composer cs:fix # Auto-fix issues
composer phpmd # Mess detection (no baseline — must pass clean)
composer phpstan # Static analysis (level 5)
composer psalm # Static analysis
composer phpmetrics # HTML metrics report
# Frontend
npm run lint # ESLint
npm run stylelint # CSS lintingcomposer check:strict is the unified quality gate; the equivalent gates are
enforced on every PR by .github/workflows/code-quality.yml (the shared
ConductionNL/.github quality pipeline). PHPMD and PHPStan
both run with no baseline — every violation is fixed at source, so the gate's
green is bought entirely by the code and not by a suppression file. The only
PHPStan suppressions are the documented ignoreErrors patterns in phpstan.neon
covering stub gaps in nextcloud/ocp (server-internal \OC classes, other apps'
OCA\ namespaces, Guzzle, Doctrine DBAL), each with a written justification.
Do not reintroduce phpstan-baseline.neon.
| Layer | Technology |
|---|---|
| Frontend | Vue 2.7, Pinia, @nextcloud/vue |
| Build | Webpack 5, @nextcloud/webpack-vue-config |
| Backend | PHP 8.3+, Nextcloud App Framework |
| Data | OpenRegister (PostgreSQL JSON objects) |
| UX | @conduction/nextcloud-vue |
| Quality | PHPCS, PHPMD, phpmetrics, ESLint, Stylelint |
Full documentation is available at conduction.nl
| Page | Description |
|---|---|
| Features | Complete feature specification |
| Architecture | Technical architecture and design decisions |
| Development | Developer setup and contribution guide |
- Data standard: CMMN 1.1 (OMG Case Management specification)
- Process standards: BPMN 2.0 for task lifecycles (DMN: roadmap — no DMN engine ships today)
- Dutch interoperability: ZGW APIs (Zaken, Besluiten, Catalogi), RGBZ information model
- Accessibility: WCAG AA (Dutch government requirement)
- Authorization: RBAC via OpenRegister
- Audit trail: Full change history on all objects
- Localization: English and Dutch
- Pipelinq — CRM intake; hands off requests to Dossiq as new cases
- OpenRegister — Object storage layer (required dependency)
- OpenCatalogi — Application catalogue
For support, contact us at support@conduction.nl.
For a Service Level Agreement (SLA), contact sales@conduction.nl.
This project is licensed under the EUPL-1.2.
All dependencies (PHP and JavaScript) are automatically checked against an approved license allowlist during CI. The following SPDX license families are approved for use in dependencies:
- Permissive: MIT, ISC, BSD-2-Clause, BSD-3-Clause, 0BSD, Apache-2.0, Unlicense, CC0-1.0, CC-BY-3.0, CC-BY-4.0, Zlib, BlueOak-1.0.0, Artistic-2.0, BSL-1.0
- Copyleft (EUPL-compatible): LGPL-2.0/2.1/3.0, GPL-2.0/3.0, AGPL-3.0, EUPL-1.1/1.2, MPL-2.0
- Font licenses: OFL-1.0, OFL-1.1
Dependencies with licenses not on this list will fail CI unless explicitly approved in .license-overrides.json with a documented justification.
Built by Conduction — open-source software for Dutch government and public sector organizations.