CRM Software Development Company

Technical architecture we applied in production multi-role platform delivery:

Role model design: We implemented a unified permission model rather than separate applications per role. A single user entity carries a role_type flag; the API layer enforces what each role can read, write, and trigger before any data reaches the frontend. This approach reduced codebase duplication by approximately 60% compared to maintaining separate admin, provider, and customer backends — and made adding the "manager" role tier a configuration change, not a development task.

SLA timer architecture: Time-bound workflows (order acceptance deadlines, payment confirmation windows, escalation triggers) were implemented as Redis-backed job queues with per-event TTL configuration. When a threshold was crossed — a provider hadn't accepted an order within the configured window — the system automatically fired an escalation event: notifying the customer, flagging the order for admin review, and optionally reassigning to the next available provider. No database polling, no cron jobs. This architecture scales cleanly to high order volumes without degrading background job latency.

Notification system scope: We implemented 16+ distinct notification event types across 3 user roles, each with different delivery channels (in-app, push, email) and different action buttons per event type. The architecture separates event emission — any service fires a typed event — from notification assembly, which is handled by a dedicated notification service that decides format, channel, and recipient based on role and event type. Adding a new event type is a single-service change with no impact on business logic.

Integration adapter pattern: All third-party integrations — payment gateway, Google Maps, Google Analytics, SMS provider, calendar booking system, online chat — were wrapped behind service adapter interfaces. When the SMS provider was replaced mid-project, the change was isolated to one adapter class. The order management service, the notification service, and the admin panel were unaffected.

Lessons from B2B multi-role platform delivery (applicable to enterprise CRM):

Audit trail is architecture, not a feature: In a B2B payment platform we delivered, the audit trail became the primary dispute resolution mechanism between three parties — sender, receiver, and agent. Every state change (who changed the status, who approved the document, who triggered the escalation) was recorded as an immutable append-only log. We implement this from day one in any CRM handling multi-party data. Retrofitting audit logging into a system that wasn't designed for it typically requires rewriting the data access layer.

Field-level RBAC is not the same as page-level RBAC: Generic role-based access control with view/edit/delete page flags is insufficient for CRM at scale. In production, you need the sales rep to see deal value but not margin; the manager to see both; the CFO to see the full financial picture including cost basis. We implement field-level permissions at the database query layer — the restricted field is never returned by the API for the unpermitted role, not just hidden in the UI. This is the correct implementation and the one that survives a security review.

SLA escalation without polling: In a multi-role fintech platform we delivered, SLA timers automatically escalated to the next responsible party when a threshold was crossed — the escalation chain was configurable per workflow type by the admin, with no code deployment required. We built this as an event-driven system: a timer event fires, the escalation service reads the current workflow configuration, and dispatches the appropriate action. The same pattern applies directly to CRM deal-stage deadlines, overdue task reminders, and unanswered lead follow-ups.