Compliance 360 Adds Formal Audit Approval Workflow with Role Separation and Record Locking

What changed

Compliance 360 now supports an optional Audit Approval Workflow that inserts a formal review gate between audit preparation and completion. When enabled, a Compliance Officer can no longer move an audit straight from In Progress to Completed. Instead the audit must pass through a submission and approval cycle.

New status lifecycle

The audit record gains several new statuses and transitions:

1. In Progress → Ready for Submission – triggered automatically once controls and Audit Insights meet submission requirements.
2. Ready for Submission → Pending Approval – Compliance Officer submits and assigns an approver.
3. Pending Approval → Approved or Rejected – approver decision.
4. Approved → Completed – Compliance Officer completes the audit.
5. Rejected → Resubmitted – officer revises and resubmits.
6. Completed → Reopened – officer reopens; the audit must go through approval again.

When the workflow is disabled, future audits skip the approval gate and move directly from In Progress to Completed. Already-completed audits are unaffected by the setting change.

Role separation

• Compliance Officer – creates/manages audits, assigns the approver, submits, completes approved audits, and can reopen completed audits.
• Compliance Audit Approver – reviews and approves or rejects. Cannot edit audit content during review.
• Compliance Audit Supporter – contributes to controls and evidence. Cannot submit an audit for approval.

Record locking

Audit records are locked against ordinary content changes in the following statuses: Pending Approval, Approved, Resubmitted, and Completed. Approvers get read-only access to audit information, controls, and attachments. Only Rejected and Reopened audits are editable by the Compliance Officer.

Toggle constraints

• The workflow cannot be enabled while any audit is In Progress.
• The workflow cannot be disabled while any audit is in Ready for Submission, Pending Approval, Approved, Rejected, or Resubmitted status.
• A reason is required when disabling the workflow.

What is missing from the source

Oracle's documentation is light on technical specifics. The release note does not mention:

• Which record type or internal ID backs the audit record (e.g., customrecord_compliance_audit or a native record).
• Whether new fields (approver, approval status, rejection reason) are exposed via SuiteScript N/record, REST web services, or SOAP/WSDL.
• Whether the status transitions fire standard workflow or User Event triggers that custom scripts can hook into.
• Governance or SuiteCloud implications for existing Compliance 360 customizations or saved searches referencing audit statuses.
• The specific release version this feature ships in.

If you have scripts, integrations, or saved searches that read or write audit records in Compliance 360, you should verify the new field availability and status values in your sandbox before the feature reaches production.

What to do

1. Review the Audit Approval Workflow Settings page in Compliance 360 to understand the enable/disable toggle and its constraints.
2. Audit existing customizations – search your account for SuiteScript deployments, workflows, and saved searches that reference Compliance 360 audit records or statuses. The new statuses (Ready for Submission, Pending Approval, Approved, Rejected, Resubmitted, Reopened) may break filters or conditional logic that only expected In Progress and Completed.
3. Update role assignments – ensure the correct users hold the Compliance Audit Approver and Compliance Audit Supporter roles if you plan to enable the workflow.
4. Test record locking behavior – if any integration writes to audit records, confirm it handles locked-status errors gracefully once an audit enters the approval pipeline.
5. Test in sandbox first – enable the workflow in a sandbox environment and verify all downstream integrations, especially any that change audit status programmatically.