# ProcessMetadataType (Complex Type)

### Namespace: http://midpoint.evolveum.com/xml/ns/public/common/common-3

Item Summary
Name | Type | Multiplicity | Description
--- | --- | --- | ---
requestTimestamp | property dateTime | [0,1] | The timestamp of "create" operation request.
requestorRef | reference ObjectReferenceType | [0,1] | Reference to the user that requested the "create" operation for this object or assignment.
requestorComment | property string | [0,1] | Comment of the user that requested the "create" operation for this object or assignment.
createApproverRef | reference ObjectReferenceType | [0,-1] | Reference to the user that approved the creation of the data (if there was such a user).
createApprovalComment | property string | [0,-1] | Comments of the approvers during the creation of the data.
createApprovalTimestamp | property dateTime | [0,1] | The timestamp of creation approval.
modifyApproverRef | reference ObjectReferenceType | [0,-1] | Reference to the user that approved the last modification of the data (if there was such a user).
modifyApprovalComment | property string | [0,-1] | Comments of the approvers during the last modification of the data.
modifyApprovalTimestamp | property dateTime | [0,1] | The timestamp of last modification approval.
certificationFinishedTimestamp | property dateTime | [0,1] | When last certification related to this item was finished.
certificationOutcome | property string | [0,1] | Outcome (URI) of the last certification.
certifierRef | reference ObjectReferenceType | [0,-1] | Reference to the user that certified the data.
certifierComment | property string | [0,-1] | Comments of the certifiers during the last certification of the data.

- ### Items

  - #### requestTimestamp

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    Display order:

    The timestamp of "create" operation request. It is set once and should never be changed.

    In case of "background" processes to create object (e.g. create with approval) this should be the timestamp when the process started. I.e. the timestamp when the operation was requested.

  - #### requestorRef

    Flags: RAM,oper

    Multiplicity: [0,1]

    Display order:

    Reference to the user that requested the "create" operation for this object or assignment.

  - #### requestorComment

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    Display order:

    Comment of the user that requested the "create" operation for this object or assignment.

  - #### createApproverRef

    Flags: RAM,oper

    Multiplicity: [0,-1]

    Display order:

    Reference to the user that approved the creation of the data (if there was such a user). This is multi-value reference therefore multiple approvers may be recorded. However the order and hierarchy of the approvers is lost.

  - #### createApprovalComment

    Flags: RAM,runtime,oper

    Multiplicity: [0,-1]

    Display order:

    Comments of the approvers during the creation of the data. Note that these comments are in no particular order, so basically it is not known who entered which comment.

  - #### createApprovalTimestamp

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    Display order:

    The timestamp of creation approval.

  - #### modifyApproverRef

    Flags: RAM,oper

    Multiplicity: [0,-1]

    Display order:

    Reference to the user that approved the last modification of the data (if there was such a user). This is multi-value reference therefore multiple approvers may be recorded. However the order and hierarchy of the approvers is lost.

    Even though this is multi-value reference it will get overwritten after each approval. The multiple values are used only if all the approvers are known at the same time, e.g. if multi-level approval is evaluated at the same time. But generally this refers only to the last approval event.

  - #### modifyApprovalComment

    Flags: RAM,runtime,oper

    Multiplicity: [0,-1]

    Display order:

    Comments of the approvers during the last modification of the data. Note that these comments are in no particular order, so basically it is not known who entered which comment.

    Even though this is multi-value property it will get overwritten after each approval.

  - #### modifyApprovalTimestamp

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    Display order:

    The timestamp of last modification approval.

  - #### certificationFinishedTimestamp

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    Display order:

    When last certification related to this item was finished. Only certifications that resulted in non-null outcome are taken into account.

  - #### certificationOutcome

    Flags: RAM,runtime,oper

    Multiplicity: [0,1]

    Display order:

    Outcome (URI) of the last certification. Only certifications that resulted in non-null outcome are taken into account.

  - #### certifierRef

    Flags: RAM,oper

    Multiplicity: [0,-1]

    Display order:

    Reference to the user that certified the data. Contrary to approver/modifierRef, this field is filled-in also when certifier denies the item status. Only certifications that resulted in non-null outcome are taken into account.

  - #### certifierComment

    Flags: RAM,runtime,oper

    Multiplicity: [0,-1]

    Display order:

    Comments of the certifiers during the last certification of the data. Note that these comments are in no particular order, so basically it is not known who entered which comment.

    Even though this is multi-value property it will get overwritten after each approval.

    Only certifications that resulted in non-null outcome are taken into account.