Add decisions and notes to a certification result
Last updated
Was this helpful?
Apply a decision, note, sign-off, or reviewer change to a numbered certification result.
Each row of the certification results can be annotated, marked as ACCEPTED, or REJECTED, signed-off, or assigned to a different reviewer.
PUT
{{base_url}}/api/preview/awf/certifications/{certification_id}/results
cert_id
string
path
id of the certification to update
value
object
body
Mutable fields to update
value must include the result_id and any mutable fields to update:
result_id
int
Y
certification result number to update
decision
enum
N
The decision to apply to the result
notes
string
N
Send an empty string " " to clear the current note
signed_off_state
string
N
Can be: NOT_SIGNED_OFF, SIGNED_OFF
reviewers
N
Contains Workflow User details for assigned reviewers
Valid decisions are:
NONE // No decision has been made
ACCEPTED // The access described in the result row is acceptable
REJECTED // The access described in the result row isn't correct
FIXED // The access was rejected but has been fixed
Adding a note overwrites the previous value. Historical notes are included in the action log when . When viewing the row in the UI, only the most recent note is shown.
reviewersA result’s reviewer can be reassigned by updating the reviewers field with a list of one or more Access Workflow User objects:
user_type
string
Y
id
string
Y
email
string
Y
Must match the email property on the local user or graph node.
name
string
Y
Must match the name property on the local user or graph node.
A successful response will be empty: {}.
array
Must be the same user_type as configured for the . Typical values are OktaUser, CustomIDPUser, or AzureADUser.
The user_identity_property set when configuring the workflows IdP is used to validate a Workflow Reviewer's identity. For an Okta user, this would be an id such as 00upa6s0hSGtl1eGL5d5. For a Custom IdP user, this will typically be the IdP users set within the OAA payload.
Note that all fields are required when assigning a reviewer. As of the current release, there is no customer-facing API to get local user ids. For this reason, API-based reviewer reassignment is recommended only when a graph IdP is configured as the , and you can programmatically retrieve required identifiers such as user "name," "id," and "email."