Best practice for two-phase PII suppression in outbound read APIs (REST/SOAP)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Community,
We are looking for guidance on implementing a two-phase PII suppression approach for outbound read APIs used by downstream integrations, without breaking existing consumers.
Requirement summary
- Phase 1: For read API responses, return null/blank values for PII fields using a business rule, scripted REST logic, or equivalent response filtering.
- Phase 2: Update the API schema/payload to remove those PII fields entirely from the response.
- Scope: All outbound REST and SOAP read APIs used by integrations.
- Field source: Suppression should apply to Tier 1 PII fields identified from the enterprise PII registry.
- Out of scope: Write APIs should not be impacted.
Currently, Our Outbound Integration is completely from flow designers and parsing the value through actions in Json format.
How to achieve this implementation in developer point of view ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @saikbandaru ,
Since your integrations are built using Flow Designer, I would recommend handling PII suppression while building the JSON payload rather than using Business Rules on the source tables.
Phase 1:
Keep the PII fields in the response but set their values to null or blank.
Example:
{
"name": null,
"email": null,
"department": "IT"
}
This allows existing consumers to continue using the same payload structure without breaking.
Phase 2:
After downstream consumers have adjusted, remove the PII fields completely from the payload.
Example:
{
"department": "IT"
}
Best Practice:
Maintain all Tier 1 PII fields in a configuration table or system property.
Create a reusable Flow Designer Action/Subflow that handles PII suppression.
Use the same action across all outbound REST and SOAP integrations.
This provides a centralized solution and makes it easy to manage future PII field additions.
Since write APIs are out of scope, apply this logic only to outbound read API payloads.