The mutation service enables property ownership changes due to sale or inheritance. It uses a configurable workflow to manage approvals and helps municipalities collect payments smoothly. The mutation APIs and flows are part of the property-services codebase and rely on configured values and integrated external services to control the mutation process.
Pre-requisites
Prior knowledge of Java/J2EE.
Prior knowledge of Spring Boot.
Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.
Prior knowledge of Git
Prior knowledge of the demand-based systems.
The following services should be up and running:
user
MDMS
Persister
Location
Localization
Id-Gen
Billing-service
URL-shortener
Key Functionality
Enables the user to create a mutation and transfer the ownership to the new owner.
Configuration Steps
1
Configure Mutation Workflow
The mutation workflow controls how ownership transfers are managed.
➤ Key Mutation Config Values
Config Key
Value Type
Purpose
is.mutation.workflow.enabled
true/false
Enable/disable the mutation workflow
mutation.workflow.name
PT.MUTATION
Workflow identifier for mutation flows
✔ What to Do
In your PT service configuration (environment YAML/properties), add the mutation workflow keys.
Ensure mutation.workflow.name is set to PT.MUTATION.
The service will use this when a mutation request enters the system.
Important: In a mutation request payload, include "creationReason": "MUTATION" so the service treats it as a mutation request. Otherwise, it won’t trigger the mutation workflow.
Sample config
To add
2
Provide Additional Details in Mutation Request
3
Integrate with Mutation Calculator
Mutation fees aren’t hard-coded — they’re calculated dynamically via a mutation calculator that the property service calls during the workflow.
💡 How It Works
The mutation calculator service evaluates a fee based on the property’s usage type and its current market value.
The workflow can invoke this service at the right point in the mutation flow to generate a fee demand.
4
Mutation Fee Logic & Billing Slabs
The mutation fee calculation considers multiple factors:
🔹 Criteria Used
Usage Type (e.g., Residential / Non-Residential)
Current Market Value (CMV)
Billing Slabs (tiered ranges of values)
Calculation Type:
FLAT → a fixed fee
RATE → a percentage of CMV
Usage type
Minimum Market value
Maximum Market Value
Rate Percentage
Fixed amount
Calculation Type
Residential
0
X lacs
A% of CMV
INR G
FLAT
Non -Residential
0
X lacs
E% of CMV
INR Q
RATE
Residential
X+1 Lacs
Y Lacs
B% of CMV
INR H
FLAT
Non -Residential
X+1 Lacs
Y Lacs
B% of CMV
INR H
RATE
Residential
Y+1 Lacs
>Y+1Lacs
D% of CMV
INR L
FLAT
Non -Residential
Y+1 Lacs
>Y+1Lacs
C% of CMV
INR I
RATE
🧮 Fee Determination
Find the slab where the property’s CMV falls.
Match the usage type.
Apply the slab’s calculation type:
If FLAT → use the slab’s fixed amount.
If RATE → calculate fee as X% of CMV (where X is the slab’s configured rate).
5
Rebate & Penalty Rules
To make mutation work in your system, follow these integration steps:
Use an existing active propertyId from the system.
Call the property/update API (/property/_update) including updated owner info and workflow details.
Ensure mutation workflow fields are part of the request so the system knows this is a mutation request.
6
Configure Integrations
To make mutation work in your system, follow these integration steps:
Use an existing active propertyId from the system.
Call the property/update API (/property/_update) including updated owner info and workflow details.
Ensure mutation workflow fields are part of the request so the system knows this is a mutation request.