Device lifecycle and inventory management system for enterprise operations. Bulk + serialized stock, RBAC, boarding workflows, and complete audit trails.
Djiminy is an enterprise device and inventory lifecycle management system built for a French organization managing hardware assets across multiple departments. Before the platform, asset tracking lived in disconnected spreadsheets — no lifecycle visibility, no audit history, no structured workflows for assigning or reclaiming devices.
Designed from Figma mockups to production delivery, covering two inventory paradigms (bulk and serialized), multi-level user hierarchies, and automated boarding workflows that handle the full device lifecycle from intake to retirement.
Bulk items tracked by quantity with threshold alerts. Serialized devices tracked individually by unique ID through every lifecycle state and user assignment.
Every device moves through defined states: Intake → Active → In-Use → Maintenance → Retired. State transitions trigger automated workflows and audit events.
Onboarding provisions devices to new users automatically. Offboarding triggers reassignment, return, or retirement flows. No manual steps required.
Multi-level hierarchy: Super Admin, Department Admin, Manager, and User. Each role scoped to precise data and action permissions — enforced at query level.
Every state change, assignment, and admin action logged immutably. Full audit history accessible to admins with time-stamped, actor-tagged records.
Per-device warranty tracking with expiry monitoring, alert thresholds, and maintenance scheduling tied to warranty status. Pre-computed nightly.
Enterprise inventory requires two fundamentally different tracking paradigms. Djiminy uses separate type architectures — bulk and serialized — with a shared query interface that abstracts the difference from the frontend.
For consumables and non-unique items: cables, accessories, standard peripherals. Tracked by stock level with threshold alerts and reorder triggers.
For unique, high-value devices: laptops, phones, tablets. Each item has a unique serial record with its own lifecycle state and assignment history.
Every serialized device moves through a defined set of states. Transitions are controlled — not all state changes are valid from all starting states — and every transition triggers a backend workflow that logs the change, updates related records, and notifies relevant parties.
Device enters the system. Serial number recorded, specs entered, warranty captured. Verified and ready for provisioning.
Device available and unassigned — in inventory, ready for provisioning. Dashboard shows available count and device list.
Assigned to a specific user. Assignment record created with start date. Manager and admin see assignment on user profile.
Flagged for repair or service. Maintenance record opened with description, return date, and responsible party. Removed from available pool.
Device end-of-life. Removed from active inventory. Historical record preserved for audit. Reason, date, and authorizing admin logged permanently.
Djiminy operates across organizational levels with distinct permission scopes per role. Access control is enforced at the data query level — not just the UI — meaning lower-permission roles cannot read records outside their scope regardless of URL manipulation.
✓ Full access · ◑ Scoped to own department · — No access
Boarding flows are the most operationally critical workflows in a device management system. Djiminy's are fully automated backend chains — zero manual steps required from operators.
Bulk and serialized inventory live in different data types. But the admin needs to search across both simultaneously. Built a stock_query abstraction layer: backend workflow running parallel constrained searches on both types and merging results into a unified display list with a type flag distinguishing rendering logic.
Device state changes must be atomic — if the audit log write fails, the state change shouldn't persist. All transitions are single backend workflow steps where the state update and audit write happen in the same operation. Rollback logic handles API errors, keeping state and audit in sync at all times.
Every query includes a :department = current_user.department constraint for scoped roles — records outside the user's scope are never returned, regardless of URL or state manipulation. Super Admin queries omit the constraint entirely.
If two admins initiate offboarding for the same user simultaneously, the same devices could be processed twice. Implemented an offboarding_in_progress lock field — set to true at workflow start and released on completion. A guard check at step 1 aborts the second flow if the lock is held.
A scheduled nightly backend workflow scans all active serialized devices, compares warranty end dates against today, and writes a warranty_status field (Valid / Expiring Soon / Expired). Dashboard reads this pre-computed status — zero runtime warranty calculation per page load.
Audit table uses a locked boolean set to true on record creation. Backend guard rejects any modification to locked records. No role — including Super Admin — can modify an audit entry through the UI or API.
Separate types for bulk and serialized. Shared assignment and audit tables. RBAC via query-level constraints.
Valid transitions defined per state. Backend guard prevents invalid jumps. Every transition triggers audit write atomically.
Lock-protected boarding chains. All device dispositions handled server-side. User account state synchronized automatically.
Pre-filtered by role. Inventory summary reads from aggregated fields. Warranty status pre-computed nightly.
Locked records on creation. Searchable by actor, device, action, date range. Full operational accountability.
Full Figma system — components, states, admin screens — signed off before build. Consistent, fast delivery.
Key screens from the Djiminy platform. Click any image to expand.
Operational shift: Device tracking moved from disconnected spreadsheets to a single live system with full lifecycle visibility. Boarding workflows that previously required emails and manual tracking now complete automatically with a single admin action.
Design philosophy: This project was designed in Figma before a single workflow was built. Full design system — components, states, admin screens — signed off before development began. More consistent product, faster build.