Object taxonomy, parts, knowledge graph and workflow — the build blueprint replacing Jira Service Management.
CustomersInfosys & C-DOT · both dedicated
CloudsAWS · GCP · Azure
VersionDesign v1 · Jul 2026
Build sequence
Six layers, built in dependency order
Brand comes first — it is the spine every other layer hangs off. Then objects, the service graph, knowledge, the workflow, and finally an AI agent layer (shared + one per brand) on top.
01 Brand
Shared "X" + one brand per customer — each a portal, domain, KB scope and access boundary.
One shared agent + one per brand — knowledge, skills, guardrails, prompt scoped per brand.
Context: Multi-tenant MSP support across AWS, Azure and GCP. Channels: portal, email, KloudMate alerts, PLuG — all through Swayam SSO. Two POC customers, Infosys and C-DOT, both on the dedicated model. Brand is the spine: it threads through objects (field), knowledge (scope), workflow (routing) and agents (one per brand).
Step 01 · Object customization
Four common subtypes, differentiated by brand
Subtypes are shared across all brands. Brand is a ticket-level field — one config, many portals.
Brand-per-customer portals
Shared "X" brand + a separate brand per customer (X-1, X-2…), each with its own custom domain. A small Swayam frontend picks the right portal link by logged-in user.
Both customers dedicated
Infosys and C-DOT each get a dedicated pool. Tickets cannot cross the dedicated boundary; resolvers are granted access per-customer × per-queue (L1/L2/L3).
Owner: Shweta — create the 4 subtypes, map subtype-specific fields, and recreate stage-transition diagrams per subtype.
Step 01 · Common (tenant) fields
Fields on every ticket
Shared across all four subtypes. Reuse DevRev stock fields wherever one exists — only build a custom field when there is no native equivalent.
Rule of thumb:stock = reuse the native DevRev field (owner, group, severity, stage, account, brand, part, SLA, source). custom = tenant fragment field, only where no native field fits.
Required at creation: brand, customer_account, source_channel, priority, stage and sla — enough to route, prioritise and SLA-track from the first moment. Everything else is optional or becomes conditionally required later (e.g. root_cause at Resolved).
Step 01 · Dependent fields
Category → subcategory, as a dependent field
Subcategory is not a free enum — its options are filtered by the selected category, using a DevRev dependent-field rule. One category taxonomy (sourced from the parts tree), no duplicated lists.
The two fields
Field
Type
Req
Depends on
Behaviour
category
enum
Opt
—
Parent — the cloud service group (from the parts tree)
subcategory
dependent enum
Opt
category
Child — only the values valid for the chosen category are shown
Modelled on Minfy's Jira cascading categories. Selecting a category on the left restricts the subcategory dropdown to the values on the right.
Category (parent)
Allowed subcategories (child)
Compute — EC2
Instance down
High CPU / memory
Auto-scaling
AMI / launch template
Connectivity
Storage — S3
Access / permissions
Bucket policy
Lifecycle
Replication
Encryption
Database — RDS
Instance down
Performance
Backup / snapshot
Parameter group
Failover
Networking — VPC
Route53 / DNS
Security group
Subnet / route
VPN / peering
Load balancer
Identity — IAM
Access request
Policy change
Role / permission
SSO
Key management (KMS)
Serverless — Lambda
Function error
Timeout
Trigger / event source
Concurrency
Deployment
Monitoring — CloudWatch
Alarm config
Missing metrics
Log ingestion
Dashboard
Cost anomaly
Security — GuardDuty / Security Hub
Finding triage
False positive
New detector
Compliance check
Remediation
Billing
Cloud billing — customer
Cloud billing — internal
Budget alert
Marketplace
Invoice query
Others
Free-text via other_category when nothing fits (mirrors Jira's "Others")
How it's built: one custom tenant field category (enum) + one subcategory (dependent enum) with a condition per category value — category == "EC2" → subcategory allowed_values = [...]. Same mechanism used for the incident root_cause-at-Resolved rule. This is illustrative; the final list is validated against Infosys's taxonomy.
Open item — Infosys: confirm the exact category ▸ subcategory tree (and Azure / GCP equivalents). The above is derived from the C-DOT / AWS Jira cascade as a starting point.
Step 01 · Subtype-specific fields
Fields that belong to one subtype
Each subtype carries all common fields above, plus its own set. Full definitions per subtype below.
Resolution Confirmation · Feedback · Not Resolved · Additional Request
linked_problem
id · problem
Opt
caused_by link to a Problem record
affected_services
id[] · part
Opt
service(s) from the parts tree / registry
Auto: when priority = Critical (P1) and resolved, the workflow triggers a Problem record and sets linked_problem. Conditional-required:root_cause becomes required at the Resolved stage (dependent-field rule) so no incident closes without an RCA note.
Service Requestservice_request
Field
Type
Req
Enum values / source
catalog_item
uenum
Req
catalog list (per-customer); default catalog when none matches
default_catalog
bool
Opt · dflt false
true · false — flags fallback catalog
approver_1
id · user
Opt
level-1 approver
approver_2
id · user
Opt
level-2 approver
approver_3
id · user
Opt
level-3 approver
approval_status
enum
Req
Pending · Approved · Rejected · Not Required
action_items
rich_text
Opt
free text — tasks to perform
expected_result
rich_text
Opt
free text — desired outcome
Approvals: up to 3 levels, run through the workflow merge node. Group-vs-individual mode is an open item with Infosys.
Change Requestchange_request
Field
Type
Req
Enum values / source
change_type
enum
Req
Standard · Normal · Emergency
risk_analysis
rich_text
Req
free text — AI-enriched risk assessment
implementation_plan
rich_text
Opt
free text — steps to implement
rollback_plan
rich_text
Req
free text — revert procedure (no prod change without one)
approver_1
id · user
Opt
level-1 approver
approver_2
id · user
Opt
level-2 approver
approver_3
id · user
Opt
level-3 approver
approval_status
enum
Req
Pending · Approved · Rejected
linked_incident
id · incident/SR
Opt
change_for link to originating ticket
Types define workflow: change_type drives the approval path — Standard (pre-approved), Normal (full approval), Emergency (expedited).
Problemproblem
Field
Type
Req
Enum values / source
rca_document
rich_text
Req
templated RCA — AI-assisted (DevRev Computer)
rca_approval_status
enum
Req
Draft · In Review · Approved · Published
rca_sla_due
timestamp
Req
RFC3339 — RCA SLA deadline
published_kb_article
id · article
Opt
KB article created from the RCA
lessons_learnt
rich_text
Opt
free text — captured on rollback / closure
affected_services
id[] · part
Opt
service(s) from the parts tree
Lifecycle: RCA drafted → reviewed/approved → published to a selected audience → KB article created; RCA SLA tracked throughout.
Dependent fields & links:subcategory options are conditioned on the selected category / part — one taxonomy, no duplicated enum tree. Custom links: Incident caused_by → Problem; CR change_for → Incident / SR.
Step 03 · Parts hierarchy
The service map is the knowledge graph
Product ▸ capability ▸ feature ▸ service. One tree, grouped by service group across AWS, GCP and Azure — shown fully expanded below (each group is collapsible). A ticket maps to a single leaf, e.g. Minfy MS ▸ AWS ▸ Compute ▸ EC2.
Migration & modernization 15 services
AWS
Rehost
Replatform
Refactor
DMS migration
SCT schema conversion
GCP
Migrate to VMs
Anthos
App refactor
DMS
Schema conversion
Azure
Migrate
Rehost
App Service
DMS
SQL schema conversion
Compute 11 services
AWS
EC2
Auto Scaling
Lambda
ECS/EKS
GCP
Compute Engine
Cloud Run
GKE
Azure
Virtual Machines
VM Scale Sets
Functions
AKS
Storage & backup 12 services
AWS
S3
EBS
Glacier
Backup
GCP
Cloud Storage
Persistent Disk
Filestore
Backup & DR
Azure
Blob Storage
Managed Disks
Backup
Site Recovery
Data warehousing 8 services
AWS
Redshift
Athena
Glue ETL
GCP
BigQuery
Dataplex
Dataflow ETL
Azure
Synapse Analytics
Data Factory ETL
Big data & streaming 9 services
AWS
EMR
Kinesis
MSK
GCP
Dataproc
Pub/Sub
Cloud Composer
Azure
HDInsight
Event Hubs
Databricks
Security & compliance 14 services
AWS
IAM
SSO
GuardDuty
Security Hub
WAF & Shield
GCP
Cloud IAM
Identity Platform
Security Command Center
Cloud Armor
Azure
Entra ID
PIM
Defender for Cloud
Sentinel
WAF
AI/ML platform 6 services
AWS
SageMaker
Bedrock
GCP
Vertex AI
Gemini
Azure
Machine Learning
OpenAI
Cognitive services 9 services
AWS
Rekognition
Textract
Comprehend
GCP
Vision AI
Document AI
Natural Language API
Azure
Computer Vision
Form Recognizer
Language Service
Monitoring & observability 9 services
AWS
CloudWatch
X-Ray
Cost optimization
GCP
Cloud Monitoring
Cloud Logging
Cost management
Azure
Monitor
Application Insights
Cost Management
DevOps & CI/CD 9 services
AWS
CodePipeline
CodeBuild
CloudFormation
GCP
Cloud Build
Cloud Deploy
Deployment Mgr / Terraform
Azure
DevOps
Pipelines
ARM / Bicep
How it renders in DevRev — the knowledge graph (Trails)
DevRev's Trails view shows the same tree as expandable columns. Each level is a searchable, filterable column with owner chips; clicking a node expands the next level. Beyond the service tree, the graph continues into Enhancements and Runnables — the same structure DevRev uses for its own product.
Mapping to Minfy: Product = Minfy Managed Services · Capability = cloud · Feature = service group · Sub-feature = service. Enhancements hold tickets/issues raised against a service; Runnables are the self-contained, github-linked automation/runbooks tied to it — so a ticket, its SOP and its automation all hang off the same node.
Open item — Infosys: the service tree is complete, but per-service field-level mappings are still AWS-only in the shared sheet. Need Azure & GCP field detail — can AI-generate from their service list.
Step 03 · Knowledge
Two bases, both linked to parts
An internal SOP/runbook base for agents, and a generic + per-brand customer base. Every article is tagged to its part so AI surfaces the right SOP.
Internal KB · agent-only
Folder structure mirrors the parts tree — visible to agents only:
Internal KB
ITSM processes
Major Incident · Problem / RCA · Change
Operations
Patch · Config · Event Mgmt
AWS ▸ Compute
EC2 patching runbook
Azure ▸ …GCP ▸ …
SRE runbooks
Linux · Windows
Customer KB · per brand
Generic base + one folder / brand attachment per customer — scoped so each sees only its own:
Customer KB
Generic(shared across brands)
Getting started · FAQs
Infosys
How-to · policies
C-DOT
How-to · policies
Scoped by brand — a customer only ever sees Generic + its own folder.
Article ↔ part link: every article is tagged to a part — e.g. EC2 patching → AWS ▸ Compute ▸ EC2. During handling, the ticket's mapped part pulls the matching SOP straight into the agent workspace.
Migration: bulk import from Confluence + incremental sync via Airsync; historical tickets from JSM.
SLA & time tracking
SLA policies, configured per customer
Each dedicated brand gets its own SLA policy with independent First Response and Resolution targets. The clock pauses on defined states and DevRev automations alert on breach. Built on the stock DevRev SLA engine — no custom fields.
Two metrics tracked
Metric
Stock field
Definition
First Response Time (FRT)
stock · SLA target
Time from ticket creation to first agent response — configurable target per customer.
Resolution Time (TAT)
stock · SLA target
Time from creation to resolution — configurable target per customer.
Time Spent / Σ Time Spent
stock · time tracking
Effort logged on the ticket — carried over from the JSM time-tracking fields.
Pause & resume
The SLA clock pauses when a ticket enters a designated wait state and resumes when it moves out:
pause → Internal Information Awaitedpause → Awaiting Customer Response
Resume triggers on any status change out of a pause state.
Breach handling
DevRev automations fire notifications on impending and actual breach — routed to defined internal contacts (with suggested content per the requirements).
SLA targets can be differentiated further by category or geography within a customer's policy.
Observed first-response times — from the C-DOT ticket dump
Derived from 267 historical C-DOT incidents (Time-to-first-response actuals). These are observed performance, not stated SLA targets — but the tight caps imply the SLA that was in force, so they anchor the proposed targets.
Priority
Tickets
Median FRT
p90 FRT
Max FRT
Proposed target
Critical
83
8 min
14 min
14 min
15 min
High
123
24 min
28 min
29 min
30 min
Medium
61
25 min
29 min
29 min
30 min
Low
—
—
—
—
1 h (proposed)
What the data shows: Critical responses cap at 14 min; High and Medium both cap at 29 min — a clear ~15 min / ~30 min FRT regime. The dump has no Low-priority incidents and its "Time to resolution" column is text-only ("Resolved"), so resolution (TAT) targets are not in the data — see open items.
Step 05 · Workflow
The automation — each workflow, top to bottom
Not one monolith. A set of small workflows, each with one trigger and one output that fires the next. Node types match the DevRev workflow designer (Trigger · Ask AI · Regex · Get relevant objects · If/Else · Update). Common = built once, shared by all brands; brand-specific = cloned per customer.
Common Brand-specific output → triggers next
W1Intake & normalisecommon
Trigger: ticket created
triggerTicket Created
↓
setSet brand + customer_account
↓
regexDedupe (KloudMate group_id)
↓
→Normalised ticket + brand
W2Classify typecommon
Trigger: brand set · customer-reported only
triggerBrand set
↓
ask aiAI reads subject + body
↓
if/elseIncident / SR / CR
↓
→Ticket subtype set
W3Severity & prioritycommon
Trigger: type set · alerts pre-mapped
triggerType set
↓
ask aiAI severity from impact
↓
setMap → stock priority
↓
if/elseP1 → major incident
↓
→Priority set
W4Part Identifierbrand-scoped
Trigger: ticket created · modelled on "Ticket Part Updater" template
triggerTicket Created
↓
regexRegex — extract service signals
↓
get objectsGet relevant objects (parts tree)
↓
ask aiAI picks the matching part
↓
if/elseConfidence check
↓
updateUpdate ticket → applies_to_part + category
Real node chain from the shared JSON: ticket_created → regex_operation → get_relevant_objects → ask_ai → if_else → update_ticket.
W5Deflect & routecommon
Trigger: part mapped
triggerPart mapped
↓
ask aiKB deflection attempt
↓
if/elseSelf-serve? → resolve
↓
setRoute: group + queue L1/L2/L3
↓
→Owner + group set
W6Approval (SR & CR)brand-specific
Trigger: subtype = SR or CR
triggerSR / CR needs approval
↓
get objectsResolve brand approvers (≤3)
↓
notifyEmail + Computer request
↓
mergeMerge node — all (individual) / any-one (group)
↓
if/elseReject → L2 queue
↓
→Approved
W7Fulfil / implementcommon
Trigger: approved (Incident skips approval)
triggerApproved / ready
↓
ask aiEnrich: suggested resolutions
↓
setWork orders · CR risk + rollback
↓
→Work done
W8Resolve & auditcommon
Trigger: resolved
triggerResolved
↓
setAuto-close 48–72h
↓
ask aiCSAT + quality audit
↓
if/elseIf P1 → open Problem + RCA
↓
→Closed
Cross-cutting (common), not steps in the chain: the SLA workflow tracks FRT + TAT, pauses on wait states and fires breach alerts; the comms workflow keeps drafting customer updates as agent notes — both run alongside every workflow above.
Why split them?
One trigger, one job, one output per workflow — so each can be built, tested, versioned and reused independently. W1–W3, W5, W7, W8 are common; W4 (Part Identifier) and W6 (approval) are brand-scoped because the parts tree, approvers, catalogs and policies differ per brand.
Merge node — where & when
Only inside W6, and only for parallel approvals: Individual = wait for ALL; Group = any ONE (single node, no merge). Requests go by Email (link / reply, no auth) and Computer (drafts + nudges). Reject → L2 queue.
Approval email — template
Sent by the workflow notification node (drafted by Computer). The approver acts inline — a link or a one-word reply — with no additional login.
From: Minfy Service Desk <support@infosys.minfy.io> To: approver.l1@infosys.com · Reply APPROVE or REJECT
Hi Priya, a Change Request on the Infosys account is awaiting your Level-1 approval. Summary drafted by Computer:
Ticket
CR-4821 · Change Request
Service (part)
AWS ▸ Data warehousing ▸ RDS
Change type
Normal · Production
Risk
Medium — brief connection reset during apply
Rollback
Revert parameter group to prior snapshot
Requested by
R. Menon · SLA: approve within 4h
Approve to proceed to implementation, or reject to route back to the L2 queue.
✓ Approve
✕ Reject
Buttons post back to DevRev · replying APPROVE / REJECT works too · no login required. Level 1 of 3 · next approver notified automatically on approval.
Reusable across SR & CR: the same template drives Service-Request catalog approvals — the fields (part, type, risk, rollback) swap for the SR's catalog item and requested action. Computer personalises tone and summary per brand.
Open item — Infosys: confirm group (any one → single node) vs individual (all → merge node) so the correct pattern is built. This decision determines whether a merge node is present.
Step 06 · AI agents
One shared agent + one per brand
The agent layer sits on top of the workflow. A shared agent carries the common MSP behaviour; each brand gets its own agent that inherits the shared base and overrides knowledge, skills, guardrails and prompt for that customer.
Agent Studio · Minfy Managed Services3 agents
MShared agent — baseinherited by all brands
◆ Knowledge
Internal SOP / runbook base · generic customer KB · full parts tree
Why per-brand: the brand field already scopes tickets, KB and access — the agent layer extends that so responses, allowed actions and guardrails are correct for each customer, with the shared base keeping common behaviour DRY. custom objectkloudmate_alert feeds the shared agent for alert triage.
Alerts & open items
KloudMate pipeline & what to confirm next
KloudMate → DevRev
Alerts arrive by webhook and land as a kloudmate_alert custom object holding raw metadata (group ID, severity, monitor, payload). A workflow decides the customer-facing mapping — same group ID appends updates; re-trigger reopens; resolve on clear. Severity is pre-mapped to stock priority (no AI classification for alerts).
Open items to confirm
Resolution (TAT) targets per priority — not present in the ticket dump.Ask Minfy / customer
Confirm First-Response targets — 15 min / 30 min implied from the C-DOT dump.Ask Minfy
SLA differentiation by category / geography within a customer policy.Ask Minfy
Do KloudMate alerts auto-become incidents? Customer-facing mapping TBD.DevRev + Minfy
This blueprint is design-only. On confirming the target org, the six layers are built in this exact order — subtypes + fields + per-subtype stage diagrams, brands, the parts tree, the two knowledge bases, the vertical workflow with the merge-node approval, and the shared + per-brand AI agents — pending the Infosys answers on Azure/GCP mappings, SLA resolution targets, and the group-vs-individual approval model.