API spec typo: WorkItemTypeManualWorkItems contains "PolicyVioloation"

Feedback Bugs
,
1

What problem are you observing?

The WorkItemTypeManualWorkItems enum in the ISC API specification contains the value PolicyVioloation. The correct spelling is PolicyViolation.

The enum backs the type property on the work item object, so it reaches GET /work-items, GET /work-items/{id} and GET /work-items/completed, and it propagates into every generated SDK. Anyone coding against the SDK enum picks up the misspelled literal.

The misspelling is present in v3, v2025 and v2026. v2024 has it spelled correctly, which suggests a regression rather than a deliberate value.

I raised this in July and it is still open:

I’m unsure if api-specs accepts pull requests. The PR is added as the diff for reference only.

What is the correct behavior?

The enum value should read PolicyViolation.

I was assuming the reason this has not been corrected is uncertainty over if changing the string would break existing consumers, so I tested what the API actually emits. Details under steps to reproduce. Across an entire tenant, neither spelling is emitted at all

Could someone confirm internally whether any service emits PolicyVioloation, and if not, get the spelling corrected in the source spec?

What product feature is this related to?

Identity Security Cloud, Work Items API. Schema WorkItemTypeManualWorkItems. Affects API versions v3, v2025, v2026. Not present in v2024.

What are the steps to reproduce the issue?

To observe the typo itself, open the WorkItemTypeManualWorkItems schema in the v2026 spec and read the enum members.

To reproduce, in a sandbox tenant, using HTTP

  1. Enumerate all identities via POST /v2026/search with searchAfter paging (1914 identities in my tenant).
  2. Call GET /v2026/work-items/summary?ownerId= for each identity to find owners holding items (7 in my tenant).
  3. Page GET /v2026/work-items and GET /v2026/work-items/completed to exhaustion for each of those owners and collect every distinct raw type value.

The only values returned tenant-wide were ManualAction (489), Form (7) and Remediation (11). Neither spelling of PolicyViolation appeared, and neither did ViolationReview.

  1. My tenant had no SOD policies, so I created one and triggered a genuine violation.
  2. Re-ran the sweep. No new work item was created.
  3. Submitted an access request that breached the policy (POST /v2026/access-requests). The violation fired and was recorded on the access request record itself:
"accessRequestPhases": [
  { "name": "SOD_PHASE", "state": "COMPLETED", "phaseReference": "sodViolationContext" }
],
"sodViolationContext": {
  "state": "SUCCESS",
  "violationCheckResult": { "violatedPolicies": [ ... ] }
},
"approvalIds": [],
"approvalDetails": [],
"manualWorkItemDetails": null

No work item was generated. SOD violations surface as sodViolationContext on the access request, not as work items, which, i am really guessing here, is consistent with this enum value being inherited from IdentityIQ and unused in ISC.

Do you have any other information about your environment that may help?

Sandbox tenant, pod stg02-eucentral1. Calls made with Python requests directly against the v2026 API, ORG_ADMIN authority.

The policy I tested had preventSetting: null. I have not tested a prevent-configured policy.