Self-Service is all end user facing interfaces combined into the feature we call "Self-Service". Below is the list of key terms you'll hear when working with Fischer.
| The "Self-Service Portal" |
| This page is the end user access request portal. This is the portal that is utilized for multiple features. The self-service portal is where approvals, profile modifications, Identity creation, access requests and delegated administration all occur. |
| Approvals |
| Fischer's approval feature is presented in the Self-Service Portal and is accessible to authorized Identities designated as approval authorities. (How do I designate an approval authority?) 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 "Approver" |
| This term is reserved for any Fischer Identity that is tagged as an approval authority. To become an approver, an Identity must have the Identity-Approver bit checked on their Identity profile. Approvers are able to access and take action on access requests when they appear in a defined "Approver's list". |
| The "Approver's List" |
| The "Approver's List" is defined within Fischer's administration user interface. There are multiple types of approvers organization's can define. You can learn about how to build approver's list here. |
| The "Requestor" |
| Within Fischer, the "Requestor" is defined as the Identity initiating an access request. This can be the beneficiary or it can be another Identity authorized to initiate requests on-behalf-of (OBO) another Identity. The typical scenario is system owners, or managers are provided with OBO privileges to support their end users in a delegated administration model. |
| The "Beneficiary" |
| The Identity(ies) to which a resource is provisioned or de-provisioned. |
| "OBO" |
| OBO stands for "On-Behalf-Of" which signifies Identities with membership to this authorization group to be able to submit and manage access on-behalf-of other Identities. This would include system or application owners managing entitlements for users of their system, managers who create and approve the access profile provided to one of their direct reports as well as help desk users who are required to have the OBO privilege before they can manage end users that contact the service / help desk. |
| "Create New User" |
| The Create New User feature is available within the self-service portal. This feature provides organizations with the ability to create new Identities directly from Fischer. This feature serves as a native source of authority for the creation of Identities. Many organizations use this feature to create external Identities such as contractors, guests and general affiliates. The feature provides the ability to create a customer form for each external Identity type to be created which helps organizations to govern the intake and creation of Identities that do not flow from authorized sources of authority (SoA). |
| "Self-Registration" |
| This is a feature that organizations to use which allows users to effectively register themselves to the organization's Identity ecosystem. Many organizations use this for third party or external users that would not typically flow through the SoAs. There are multiple use cases for this feature which will be discussed in the feature guide associated with "How and When to use Self-Registration" |
| "Self-Profile Update" |
| This is a feature within Self-Service that enables end users to manage their Identity profile. This feature can be turned on and off, and can also be used dynamically be defining which user groups are allowed to see and use the feature. Governance of the availability of this feature to different Identity types is defined within Fischer's authorization feature. |
| "Security Q&A" |
| This is a feature widely deployed across the majority of the customer base. This feature is the standard challenge mechanism used for Identity Verification that presents a list of questions to end users when they are attempting to reset their password. Refer to the "How and When to use the Security Q&A Feature" guide for specifics regarding how to deploy this feature. |
| "Login Alerts" |
| Login Alerts is a feature within the product that enables IGA Administrators to alert users once they authenticate to the Self-Service interface. There are two features involved in the Login Alerts feature. There is a local alert which can either be a custom message you want to alert users about, or it can be an Acceptable Use Policy that users are forced to accept before they can continue into the Self-Service portal. There is also a global alert configuration that is used and is accessible from the master organization. (refer to the Global Administration Guide for details regarding the master org). If a global login alert is configured it will notify all users in all client orgs. This feature is used for communicating global messages such as impending maintenance activities to Fischer's cloud customers. |
| "Dynamic UI" |
| The "Dynamic UI" feature is located within the administration user interface. It's a powerful feature that provides organizations with the ability to build dynamic user interfaces that will appear within the Self-Service portal. |
| "Validation" |
| This is the term used to describe field-level data validation that can be performed within self-service. The Dynamic UI feature provides a mechanism to build validation scripts using LDAP, SQL, Regular Expression, etc. |