Best practice for two-phase PII suppression in outbound read APIs (REST/SOAP)

[saikbandaru]

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 ?

[Vikram Reddy]

Hey @saikbandaru,

Since your outbound path is mostly Flow Designer building the JSON, the cleanest Phase 1 approach is one reusable redaction layer instead of PII logic scattered across integrations. The mechanism differs by channel though:

• Scripted REST APIs: you own the response object in the resource script, so just null the Tier 1 PII keys before res.setBody(). No ACL dependency at all.
• Table API and direct SOAP web services: both enforce field level ACLs, so a "read" ACL on each PII field that evaluates to false blanks the value automatically. For SOAP, this only kicks in if the glide.soap.strict_security property is enabled, worth confirming that first since it also drives contextual security for those endpoints.
• Flow Designer actions like Look Up Record often run in system context, and system/admin bypasses ACLs unless Admin overrides is unchecked on that specific ACL. So don't lean on ACLs alone here, add an explicit Script step that strips the Tier 1 fields from the record or JSON before your JSON-build step runs.
• Keep the field list in one Script Include, fed off your PII registry, and call it from every flow and resource script. That way Phase 2 is deleting entries from one list, not hunting through every integration.

Phase 2 itself is easy on Scripted REST, just drop the field from the response and the Swagger/API definition. Direct SOAP web services don't have that schema layer since the WSDL is auto-generated off the table structure, so true field removal there usually means retiring the endpoint rather than trimming it.

Happy to dig into specifics if you tell me which of these three you're actually running for the read side.

Thank you,
Vikram Karety
Octigo Solutions INC