This document collects the questions CIOs and Heads of Operations raise when evaluating the OKAXI operational management software. Answers are written from hands-on production operation of retail and contract management deployments.
Yes. OKAXI designs the core engine as configurable rather than hardcoded. Every enterprise workflow is defined through a JSON schema with nodes (action, condition, approval) and edges (transition). The client admin edits the workflow through the admin panel without requiring OKAXI to redeploy code. Some clients run more than 50 different workflows for different departments on the same instance.
OKAXI uses a form schema that separates the JSON Schema and the UI Schema. Each field carries metadata covering name, data type, validation rule, dependency, and visibility condition. The admin adds fields, hides fields, or relabels fields through a drag-and-drop interface. Data migration on schema change is automatic through versioning, and older data remains readable after a form upgrade.
Yes. OKAXI manages workflows by version. A running workflow stays unchanged for records already created. New records run the new workflow version. When in-flight records need to migrate to a new version, the admin runs a migration script with explicit mapping rules. The process avoids abrupt machine-state changes and preserves business consistency.
A simple 5 to 7 step workflow is configured in 2 business days by a trained client admin. A complex workflow with more than 20 nodes, multi-level approval, and external system integration takes 1 to 2 weeks of engagement with the OKAXI BA. Every workflow runs in a sandbox for testing before being promoted to production. OKAXI provides 4 training sessions for 3 to 5 client admins during handover.
OKAXI applies dedicated indexing techniques per query pattern. Hot tables carry composite indexes on (tenant_id, status, created_at). Cold data archives into a separate table with compression. Partitioning by time range or tenant prevents full table scans. On the live retail project, the contract table holds 1.2 million records and still returns p95 under 200 milliseconds for a list view of 50 rows filtered by 3 columns.
OKAXI builds contract management on command-query responsibility separation (CQRS). The command side writes to normalised tables for data integrity. The query side uses a denormalised read model synchronised via Kafka events. The read model carries pre-computed aggregates (count by status, sum by amount) so the dashboard never recomputes from raw.
OKAXI uses a dedicated time-series database (TimescaleDB or InfluxDB) for GPS events. Each field rep sends one ping every 30 seconds from the mobile app to the backend over MQTT or HTTP batch. The backend writes into the time-series store with automatic compression on data older than 30 days.
OKAXI splits reporting into three tiers by complexity. Tier 1 (real-time dashboards, under 1 second) runs on materialised views refreshed every 5 minutes. Tier 2 (detailed reports, under 30 seconds) runs ad-hoc queries with a streaming cursor. Tier 3 (heavy cross-domain reports, several minutes) runs through a job queue with the result delivered by email or download link. Users get a notification rather than waiting on a blocking UI.
OKAXI uses object storage (S3 or S3-compatible) for the original files and PostgreSQL for the metadata. Text files are indexed for full-text search through Elasticsearch or PostgreSQL pg_trgm depending on scale. PDFs are automatically extracted to text through tika-server and pushed into the index. Clients search content across more than 50000 PDF files with p95 latency under 500 milliseconds.
OKAXI combines role-based access control (RBAC) with attribute-based access control (ABAC). RBAC defines roles and grants permissions across the organisation tree. ABAC adds runtime conditions, for example only view contracts of the region the user manages. Every permission check flows through a central policy engine written with Open Policy Agent (OPA) or Casbin so every authorisation decision is auditable.
Yes. Row-level: each record carries owner_id and scope_id, and queries filter automatically based on the user context. Field-level: each form field carries a visibility rule and an editability rule. Sensitive fields such as salary or contract value are only readable by specific roles. Permission rules are declared, never hardcoded, and the client admin can update them without requiring an OKAXI redeploy.
The audit trail records six dimensions per event. First, the actor (who). Second, the action (what: create, update, delete, view, export). Third, the target (which record). Fourth, the timestamp. Fifth, the before and after diff (old and new values). Sixth, the context (IP, device, session_id). Logs land on append-only immutable storage with a SHA-256 chain to detect tampering. Compliance reporting exports to CSV or connects directly to the client SIEM.
Yes. Any document type can attach an approval flow with any number of levels. Routing rules are configured by amount range, region, department, or custom conditions. Each level has a timeout that automatically escalates to the next level. Approvers receive notifications through mobile push, email, and in-app. Approvers can delegate to another user within a defined window. The approval history is fully recorded in the audit trail.
OKAXI exposes REST and GraphQL APIs to OpenAPI 3.0 and GraphQL SDL standards. Every resource has a standardised CRUD endpoint and OData-like filter syntax. Authentication goes through OAuth 2.0 or API key depending on the use case. Webhooks ship every event with an HMAC SHA-256 signature header so the client can verify origin. Rate limits are configured per API key. Documentation is auto-generated and published at /api/docs with try-it-out on Swagger UI.
OKAXI designs the core as a plugin architecture. Every business module is a plugin with a contract that declares the events it subscribes to and the APIs it exposes. New features ship as new plugins without modifying core code. Plugins are enabled per tenant through a feature flag. Clients can build their own plugins and deploy them into their instance through an internal marketplace, with OKAXI reviewing and approving security.
