1. Scope
Administer local Workflow for small teams and associations. Read the installation and user guides first. Public intake, mail transport and accounting integrations require their own configuration and operational acceptance.
2. Initial setup
Create the first administrator only in an empty installation. Use a named account and a strong password. Existing login screens indicate an existing database; preserve it when recovering access.
3. Languages
DE, EN, IT and FR are selected per browser and remembered locally. System labels and help change language; customer texts, names and uploaded documents do not. A language change does not create a new account or database.
4. Licences and trial
Activate the purchased licence and verify seats and expiry. The free trial allows two active users including administrators for 14 days from first launch. Deactivated accounts do not count as active seats. Do not delete trial state to extend the trial.
5. User accounts
Create one account per person, assign the minimum necessary role and review active seats. Disable departed staff promptly. Test role changes using a separate non-administrator account; hiding a button alone is not an access control.
6. Role boundaries
Administrators configure the system. Caseworkers process permitted cases; approvers make permitted decisions; applicants submit and follow accessible requests. Server-side permissions and assignments govern every action. Check actual visibility with synthetic accounts.
7. Organisation
Create teams and areas of responsibility before assigning cases. Check parent relationships and active status. Select a responsible person separately from the team and area, then save and verify the displayed result.
8. Process starters
Seven starters cover customer enquiries, purchases, expenses, document reviews, membership, events and reimbursements. New installations seed them automatically. Existing customer definitions are preserved. Each case stores a snapshot of its required fields and process rules.
9. Workflow versions
Publish a new workflow version for intentional configuration changes. Existing cases retain their applicable version. The seven-state engine remains shared; this release does not provide an arbitrary graphical state-machine editor or automatic escalation service.
10. Required fields and deadlines
Validate required fields, positive monetary amounts and dates before submission. Starter defaults propose a deadline; staff must verify it. Edit process details only in draft or revision. A displayed deadline does not guarantee a reminder has been delivered.
11. Separate approval
Internal and association decisions require a second authorised person, distinct from the requester and responsible processor. Assign an approver or let an eligible distinct approver take the decision. Never share an administrator account to bypass this separation.
12. Document checks
Expenses, document reviews and reimbursements need at least one clean document before approval. Configure the supported scanning service and inspect failures. A blocked, pending or failed scan does not satisfy the requirement. Never mark a document clean without a legitimate check.
13. Comments and access
Explain internal and external comment visibility to staff. Check access with a separate applicant account. Store only necessary personal data and attach documents to the correct case. External visibility is not proof of email delivery.
14. Customer responses
Customer enquiries cannot close without a recorded response. Staff must explicitly confirm that the response already occurred and provide a dispatch reference for email, letter or portal. This record sends nothing. Revision clears the previous response so it must be checked again.
15. Mail and notifications
Configure transport, sender and templates before enabling automatic delivery. Enter credentials only in protected local configuration. Test with a synthetic recipient and verify receipt. Monitor queued and failed deliveries; distinguish provider acceptance from delivery to the recipient.
16. Customer forms and email intake
Maintain distinct saved forms with stable keys, preview and test submission. A locally saved form is not automatically public. Publish only through an approved hosting integration. For incoming mail, verify deduplication, durable storage, handover reference and recovery before real use.
17. Tasks and reporting
Assign tasks and deadlines to named staff and review overdue items. Use reports to track workload and completion. Local AI assistance requires its own configured service; verify suggestions before using them. Generated suggestions do not make approval decisions.
18. Fees and accounting
Maintain fee rules administratively and verify invoice data before accounting export. Record the export reference and reconcile it in the accounting tool. Approval of expenses or reimbursements never proves a payout. No bank transfer is triggered by the new starters.
19. Integrations
Use a separate restricted credential per integration where supported. Check endpoint, mode, field mapping and retry behaviour with synthetic data. Do not treat a created handover as successful import; inspect the target acknowledgement and retain the external reference.
20. Backup
Back up the actual configured database, documents, settings and recovery material consistently. Use the supplied backup process or stop the app before copying. Schedule recurring backups to C and an independent device such as a NAS. Check completion, free space and failure alarms. Keep recovery keys separate.
21. Restore and updates
Test restoration into an isolated directory, never over the only production copy. Check login, case counts, documents and audit integrity. Preserve the previous executable and pre-update backup. Perform upgrades on a copy first and document the rollback path and accepted downtime.
22. Retention and deletion
Define retention periods for your organisation, including documents, mail, audit evidence and backups. A deletion review date does not itself delete data. Check legal and business obligations before removal and include backup expiry in the retention plan.
23. Operational checks and incidents
Check startup, backup age, queued deliveries, failed integrations and available disk space regularly. Nominate an owner and a recovery target. During an incident preserve logs, pause affected intake, prevent duplicate processing and restore only from verified evidence.
24. Acceptance and support
Before release test a customer enquiry through response and closure, a separate-person approval, a required-document rejection, role boundaries, all four languages and a restore. Record version, results and rollback path. Contact support@alkensdevelopment.ch without passwords, licence tokens or unnecessary personal data.