Notifications:
Fischer's approval feature is presented in the Self-Service Portal and is accessible to authorized Identities designated as approval authorities. Once an approval is initiated, all relevant parties will be notified of the pending request. Once received the approver will access the Self-Service Portal to view and take action on any pending requests. The remainder of this article will outline Fischer's approval features.
General Notifications:
*Selecting the checkbox and then "Search" will allow you to select any customized notifications that may have been configured.
| Assigned to Approver | ||
| This notification will go to the approver(s) when an approval is assigned to the individual. | ||
| On Completion to Beneficiary | ||
| Once an approval has been processed, this notification will communicate the result (approved or denied) to the beneficiary | ||
| On Completion to Requester | ||
|
Once an approval has been processed, this notification will communicate the result to the requester (approved or denied) Note: The requestor may not be the beneficiary of the request. Fischer provides a feature where OBO users can submit access requests on-behalf-of other users so there could be scenarios where requestor notification and the beneficiary notification will be sent to separate individuals. |
||
Administrator Notifications
Fischer provides the ability for the relevant parties to be notified of a pending approval, or any status update that may occur during the process. Fischer provides the following out of the box notification options for approvals:
The radio button "Use Default" will auto populate the notification with the default admin notifications available out of the box.
| Approved | |
| Fischer also reserves a section of the approval feature to notify IGA Administrators or other governing entities within the organization. Fischer's scalability and focus on reusability is where this feature may be useful. For certain approvals, where sensitive resources such as high profile or privileged access is the requested resource, it may be useful to an organization to notify a global list of approval administrators when specific resources flow through an approval process and ultimately lead to approval. | |
| Denied | |
| Much like the approval notification when an item is approved, Fischer also provides a mechanism to notify the same list of global administrators, possibly including governance and compliance entities when a request is denied. | |
| Failure | |
| This notification is reserved for notification of a failed approval process. A failure can occur for multiple reasons. Refer to the Configuring Approvals Guide for more details. | |
| Timed-Out Denial | |
| This notification will be sent if an approval request times out and the exception configuration is to automatically deny the request if the approval is not acted upon. This can be a powerful function to inform global administrators, governance and compliance entities that approval authorities may not be performing their duties. This can help organizations to provider oversight to their business process to ensure it is in fact being followed. | |
Event Specific Notifications
This section is reserved for configuring preferential notifications.
| Auto-forward to Approver | |
| If the exception logic is initiated as a result of a timeout or approval failure, this notification will be sent to the designate approval authority(ies) letting them know that an existing approval request was forward to them as a result of Fischer's approval engine invoking the exception handling functionality of the approval feature. The distinction here is that the receiving party will be aware that this notification is a forwarded approval request. This is important when you consider the fact that if this notification is sent, something went wrong with the defined approval process, and an exception occurred. The existence of this notification helps businesses to ensure continuity in their business processes and provides intelligence into whether or not their process, and the entities involved are actually performing as expected. | |
| Denied to Approvers | |
| This notification is reserved for approval authorities that may have already acted on an approval and the request was denied at a higher layer in the approval process. For example if an approver has approved the request, but the next layer of approvers deny the request, this notification will be sent to the approver(s) that approved the request letting them know that ultimately, the request was denied. This approval feature is a powerful feature for businesses to maintain communication upstream and downstream. | |
| Reassign a Request | |
| When an approver reassigns a request to another approver, the receiving approval authority will receive a specific notification informing them that an outstanding request has been reassigned to them. | |
| Request For Info - Request | |
| Within Fischer's approval feature there is an option to initiate a dialog with the approver and the requestor. The "Request Info" function will be discussed in more detail further down this guide. This notification informs the requestor that the approver has requested more information before taking action on the approval (i.e. approve / deny). This is a feature built for extending efficiencies within the organizations business process as well as keeping track of the communication within the scope of the request itself. This feature provides a method of communication between the relevant parties in a more efficient way than exiting the request, and making a phone call or sending an email outside of the process. This feature allows organizations to capture the conversation between parties and it is forever archived so at any point in time, maybe during an audit (hint, hint) the commentary that led to the approval or denial of the request can be referenced. This is an important feature no only for business process efficiency, but also for auditing purposes. | |
| Request For Info -Reply | |
| Within the same scope of the Request for Info - Request function, this notification will be the notification sent back to the party that initiated the "Request Info" conversation within the approval request. | |
| Self-Registration Request for Info - Reply | |
| Self-Registration is a feature that will be discussed in a separate guide. The notification will follow the same guidelines as the Request for Info functionality we just explained. The difference is this provides an organization that allows end users to be onboarded | |
| Self-Registration Request for Info - Request | |
If the approval authority responsible for approving self-registration requests for Identities, this is the notification that will be sent back to the registration candidate. Note that the registrant does not yet have an identity within Fischer during this process. Fischer accounts for this with offering self-registered users the ability to specify an email address to be used by the feature to communicate with the registrant. |
|
| Self-Registration Request for Info - PIN | |
| During the process when a self-registrant is required to respond to a request for more information from the approval authority. Fischer provides a mechanism to verify the candidates identity. Once the identity is verified, a notification is sent to the email address the registrant provided while filling out the registration form. This feature provides organizations with a layer of external governance to properly vet external users BEFORE they qualify for an Identity. When employed this feature provides for consumer identity services to begin to take form within an organization's IGA Program. | |