DCIM, service desk, field ops and purchasing, on one record
One platform from rack to ticket.
Most data centres run on a DCIM tool, a separate service desk, spreadsheets and a purchasing system, kept in step by hand. Divjyot ONE puts the floor plan, the power chain, every cable, every ticket and every purchase order on one shared record, so a change made in one place is true everywhere.
9 modulesInventory to invoices, sharing one record instead of nine tools
1 moveupdates the rack, its cables, the floor plan, the 3D view and the history at once
2 ways to run itOn your own servers, or hosted with a database and key of your own
0 editsto the audit trail, by anyone, administrators included
Why one record
Three tools means three versions of the truth
Every data centre team knows the drift: the drawing says one thing, the ticket another, the rack a third. Divjyot ONE removes the hand-offs that cause it.
How it usually goes
A server moves on Friday; the DCIM drawing is updated next month, if at all.
Its cables stay documented in the old rack, so the next trace leads nowhere.
The incident in the service desk names a hostname, not a rack, row or power feed.
The change approval lives in one tool and the move it approved in another.
Finance knows a server was bought, not where it went or what it replaced.
With Divjyot ONE
A move is made in the app, in 3D or on a phone, and the floor plan follows at once.
Its cables move with it: re-patched to matching ports in the new rack, or listed for the technician.
Tickets know the device, rack and business service they're about.
The MAC request that approved the change carries it out, through the same rules.
The purchase order, the delivery, the rack it went into and its warranty are one story.
One move, every record
Follow one change through the whole platform
A rack runs warm. Here is what happens next in Divjyot ONE, without anyone copying a detail from one system into another.
Monitoring
An early warning
Rack B04's inlet temperature is trending up. The alert rule warns before the limit is reached, and names the rack and the room.
Service desk
An incident on the right rack
The alert raises an incident on the rack itself, with its devices, power feeds and the services that depend on them a click away.
Change control
A move, approved
A MAC request to move a server to rack A02 is approved by someone else, within its change window.
Moves
Cables that follow
The server is moved. Its cables to the old rack's switch and PDUs are re-patched to free ports of the same kind in A02; the dialog shows each one first.
Field ops
Checked on the floor
A technician scans the asset tag, or audits the rack with a phone's camera. A device found somewhere else is updated to where it was found in one click.
Audit trail
Nothing to reconcile
The device's location history, each cable's history and the change are recorded. The 3D view, reports and capacity figures are already up to date.
See how one platform compares with spreadsheets, a stand-alone DCIM tool and a separate service desk.
AI and integrations
AI that shows its work, and connections to what you already run
Suggested fixes on tickets come back as a plan to review; scripts are never run by the app. Triage suggests how to file a ticket and what an alert means. An assistant answers questions about the estate by reading, never changing. Camera audits read labels on the phone itself.
Connections read your virtualisation platforms, clouds and building management systems as well as your service tools. Each is tested against a simulated version of the other system, following its published interface, and checked with yours when you start.
It's the same application either way, built from the same release. You can start hosted and move on-premises later, or the other way round.
On-premises
Run it in your own environment
Install it in your Kubernetes cluster, with your own database, identity provider and storage. Your data never leaves your network.
One installation per organisation: its own database, secrets and sign-in.
Your people sign in with your identity provider (Microsoft Entra ID, Okta, Google and others).
A deployment guide and go-live checklist, and help from our team.
Hosted: Divjyot ONE Cloud
Let us run it for you
Every customer gets an instance of their own: its own database, storage, encryption key and web address. No two customers share an application or a database.
Standard, or Dedicated with database servers and machines of your own.
Upgrades, monitoring and nightly backups are our job.
Sign in with your identity provider, or with accounts we host, with an authenticator app.
Hosted starts in the United States; India is planned next. Compare the plans.
Security
Separation and control, built in
Access comes from your identity provider's groups, per environment, and is enforced by the database itself. Every change is in an append-only audit trail. Hosted customers each have their own database and encryption key.
Single sign-on with OpenID Connect; multi-factor authentication for hosted accounts.
Roles granted per environment, enforced by row-level security in the database.
An audit trail that nobody can change, administrators included.
Two people for the risky actions: deleting a hosted customer, or restoring their data.
Design partners
Help shape what comes next
Divjyot ONE is new, and we're choosing our first customers carefully. Design partners work directly with the people who build it: we help bring your sites, racks, cables and current tools across, and your priorities shape the roadmap.
