AI in Divjyot ONE suggests, reads and drafts; people decide. It's off until an administrator turns it on, with your own AI provider. And the platform connects to the service desks, chat tools, virtualisation platforms, clouds, collectors and finance systems you already use.
Every AI feature comes back as something a person reviews: a plan, a reading, a draft, a suggestion. Nothing it suggests is carried out on its own: a person uses it, or a rule an administrator set up does.
Ask your AI model what to do about a ticket, and keep its answer as a plan: what it found, what to do, the risk, the steps, and any script for someone to review. The app never runs a script. If the plan is to retire or archive a device, a person confirms it, and the usual device rules apply.
Turn a resolved ticket into a knowledge article draft, for a publisher to check and publish. Each article shows where it came from: written, imported, from a ticket or drafted by AI.
A phone's camera finds the rack from printed markers, draws each recorded device over its slots and reads asset labels on the phone itself, even offline; nothing is uploaded. An optional vision model, with your own key, reads what the phone can't.
An MCP server lets AI assistants read devices, racks, sites, alerts, tickets, knowledge, capacity, forecasts, failure risk, unusual readings and what needs attention first, with seventeen read-only tools. Each person approves access for themselves; a tool sees only what they may see, and can change nothing.
Ask about the estate from any page, such as which racks run out of power first, or what's unusual today. Your AI model answers through the same read-only tools as the MCP server, as the person asking, so it sees only what they may see, and each answer says what it looked at. Nothing of the conversation is kept.
On a ticket, your AI model suggests a category, impact and urgency, a group, the device and likely duplicates, picking only from what it was offered. On an alert, it gives the likely cause and what to check first. A person uses a suggestion through the ticket's usual edit, or an automation rule applies it.
AI features are off until an administrator turns them on under Integrations › AI model, choosing the provider and accepting what is sent; the assistant and triage each have a switch of their own. Suggested fixes send ticket details without people's names or email addresses. The assistant sends the question and what it reads to answer it. Camera audits read on the phone; the vision model is used only if you add one.
The assistant and triage are tested against a simulated AI service, and the MCP server without a real AI tool, so all three are marked early access. We check them with your provider and tools when you start.
Bring your data in, send events out, and keep the systems you rely on in step.
Tickets sent with their public comments, and their status read back: ServiceNow (incidents, and devices to its CMDB), Jira Service Management, Zendesk, Freshservice, BMC Helix, GitHub, Asana, Linear, ClickUp and monday.com. ServiceNow's incidents, changes and requests can be pulled in as tickets too.
Read Sunbird dcTrack's items and cabinets, or Schneider Electric EcoStruxure IT Expert's devices, into an import to check and confirm; IT Expert's alarms can arrive as alerts. Salesforce assets and any REST API can be read the same way.
Microsoft Teams and Slack channels, signed webhooks and email notifications. Alerts and urgent tickets go to Datadog and Dynatrace as events, and their alerts come back here.
Articles imported as drafts from Confluence, Zendesk Guide and ServiceNow's knowledge base, for a publisher to check.
Collectors on your network discover equipment over SNMP and LLDP, and poll devices over SNMP, Modbus and Redfish. Sensors can also send readings to the ingest API. Every collector shows in one list: sending, late or silent.
BACnet/IP points from your building management systems, read by the reference collector directly or through a BACnet router for MS/TP devices. The points to read are set in Divjyot ONE, so a new sensor needs no change at the site.
Templates read common equipment over SNMP, Modbus and Redfish. New: Legrand PDUs (Raritan, Server Technology) through their JSON-RPC API, and coolant distribution units through DMTF's Redfish thermal model, both so far tested against simulated devices. UPSs are read over SNMP; no UPS maker's own API is included.
Purchase orders, invoices and fixed assets as CSV or JSON, or in the formats Tally, SAP, Dynamics 365 and Oracle FBDI take.
Sites, rooms, rows, racks, models, devices, cables, vendors, contracts and parts from spreadsheets, with a preview of every row before anything changes, and undo afterwards.
Single sign-on with OpenID Connect: Microsoft Entra ID, Okta, Google and others. Read-only API tokens, scoped to the environments and data they need.
A partner can add a system without changing Divjyot ONE. The connector SDK has a module, a checker and a complete example of a small web service that sends equipment to the discovery inbox, and clusters, hosts and VMs to the virtualisation inventory.
Six virtualisation platforms and three clouds, all read-only. What each reads, and how.
Each connection and finance format is tested against a simulated version of the other system, following its published interface; we check it with your own system when you start.
Clusters, hosts and VMs come into one inventory, each host matched to the server it runs on. What each platform reads, and how:
Clusters, hosts and VMs through the vSphere Automation REST API (vCenter 7.0 Update 2 or later), and each host's serial number, network cards and addresses through the VI/JSON API (8.0 Update 1 or later). vCenter's Read-only role is enough.
Failover clusters, hosts and VMs, sent over HTTPS by a PowerShell script you schedule on one of your machines, so nothing calls your hosts. The script only reads, but Hyper-V has no read-only role: its account needs the Hyper-V Administrators group.
AHV clusters, hosts and VMs through Prism Central's v4 APIs (pc.2024.1 and later), with a Viewer's user name and password or a service account's API key.
A cluster's nodes, VMs and containers through its API, with a token that has the PVEAuditor role. Proxmox gives no serial numbers, so nodes are matched by name, then address.
Compute hosts, availability zones and every project's servers from Nova, signed in to Keystone with an application credential. Hosts are matched by name, then address.
Nodes and pods, with what each pod requests, through a service account token that may get and list them. A node that is a VM another connection reads is linked to that VM, and its pods to that VM's rack.
Each platform is tested against a simulated version built from its published API, not yet against a real one. We check it with yours when you start.
Instances and databases come into the cloud resources register under Purchasing › IT estate, read on a schedule or on demand. Nothing in the cloud is changed.
Reads EC2 instances and RDS database instances in the regions you choose. Terminated instances aren't kept.
How with an access key whose requests are signed with Signature Version 4, so the secret is never sent. Its policy needs only ec2:DescribeInstances and rds:DescribeDBInstances; AWS's ReadOnlyAccess policy covers both.
Reads the resources in the subscriptions and of the kinds you choose, such as VMs, SQL databases, storage accounts, web apps and AKS clusters, with each VM's power state.
How through Azure Resource Manager, signed in as an app registration in Microsoft Entra ID with a client secret and the Reader role.
Reads Compute Engine instances in every zone, and Cloud SQL instances, in the projects you choose.
How with a service account's key, which signs a request for a read-only token at Google's own sign-in address. The Viewer role, or Compute Viewer and Cloud SQL Viewer, is enough.
At each read, a resource's name, kind, region and state are updated. What your people add is kept: its monthly cost, the device it's linked to, its vendor, owner and notes. A resource no longer listed is marked, not removed.
These connections are tested against simulated AWS, Azure and Google Cloud services that check each request's signature or token. They haven't yet been tried on a real cloud account; we'll check one with yours when you start.
We'll show you how Divjyot ONE would fit in, and what it would replace.