Approval Step

the approval step in a workflow allows user interaction with the job at a minimum the approval step has a target list of users a notification email target list each approval step has a list of target list can can approve the request the target list can be a reference to any object that then resolves to an active directory user or group this list is resolved at the time the approval is sent subsequent changes will not be reflected target users if the target list resolves to a user then the user in included in the list of users can can approve the request the users guid is stored as the approver this means that if the user's account is deleted or recreated then they will not be able to approve the request however, renaming the user account will not affect there ability to approve the request target group if the target list resolves to an active directory group, then the group is made the approver this means that changes to group membership will be reflected in the ability to approve the request for example, sending approval to the 'financial approvers group' means that any users in this group can approve or decline the request this includes users add after the approval was started it is assumed that the target group is mail enabled and notification emails are sent to the group rather than individual users notification email the notification email should include the basic information on approving the request and will normally include a link to allow the approver to directly approve the request other options the following section outlines other options for configuring approvals approval type and required approvals the following are the available approval types true left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type by default only one approval if required to approve or decline a request however, this can be override by changing the required approvals property valid options are true left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type submitter approval this option controls what happens if the submit user is also an approver valid options are true left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type previous approvers this option controls what happens if multiple approvals are required for a request for example, if a 'manager' and 'financial' approval step are required and a user can approve both steps, do they need to do two seperate approvals or just one? true left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type timeouts the activate timeouts are a declarative way of specifying what happens after a period of time when an approval step is running if this is not specified for a specific approval step, then the default values are obtained from //resources/configuration/defaultapproval the defaultapproval timeouts are every 2 days send a reminder email to all current approvers after 5 working days escalate to the approvers manager after 8 working days escalate to the service desk role advanced options there are numerous advanced options for controlling the approval screen and ui these options include options for overriding the button text and displaying additional information