Service Panel runs on top of the Identity Panel web platform. It is configured through the Identity Panel settings interface, but is hosted using independent application logic on a separate URL.
For a description of Service Panel and feature comparison see:
Service Panel uses the Identity Panel REST API for servicing requests. The web maintenance service processes Track & Trace operations, and the Identity Panel workflow engine handles changes made by service forms.
Many of Service Panel's interfaces and capabilities depend on the virtual identity concept. A virtual Identity uses the contents of the Identity Panel data silos to display objects and populate update forms.
A virtual identity should be thought of as the heart, or core representation of an identity that may span multiple systems. A user or group may have silo records in MIM, HR, AD, or O365, but those are really all different aspects of the same identity, and when those disparate silos are joined together in Identity Panel, they create a graph which represents the identity as a whole. The Service Panel virtual identity is a projection/transformation of that identity into a view that is suitable to display to end users, and to manipulate as needed for Service Panel features.
Service Panel can have an arbitrary number of virtual identities defined, e.g. for groups, users, computers, contacts, devices, or other objects. A virtual identity is a view and transformation on an Identity Panel silo join-graph.
A virtual identity must choose a single Identity Panel silo and object type (e.g. MIM Metaverse person, or Active Directory user) as its root. The root silo may then be filtered based on viewer audience, and properties of objects within the silo. The filtered root silo defines the scope of objects included in the virtual identity. For example, a virtual identity might contain all active employees in AD.
A single virtual identity may be designated as primary. This means it contains records corresponding to Service Panel login users, and thus masters security for referential audiences (see Service Panel Audiences). The primary virtual identity is the one which has a "Self Lookup Claim" defined.
Having a "Self Lookup Claim" means that the virtual identity is able to take either the Id (AD ObjectSID or Azure GUID) or Identity (AD sAMAccountName or Azure UPN) claims from the user's authentication token, and query for the object in the root silo which matches the current user.
Once a root silo is defined, a virtual identity may include attribute data off of any of the silos joined to the root silo. For example, a user virtual identity may choose AD as the root silo, but report some attributes from the MIM Metaverse, for from Office 365.
Best practice for Service Panel is to minimize the number of silo dependencies for each Virtual Identity, as there is a modest performance impact when more data must be loaded to display the object.
Like virtual identities, service forms are a major ingredient to Service Panel's feature set, and understanding how to create and integrate service forms is key to a successful Service Panel deployment.
By itself a service form doesn't actually do anything but collect data for a set of fields. The real magic is in how the form is populated, and how the results are validated and acted on. Submission of service forms uses the following basic process:
- Activate the form based on Id or Name
- Load an optional pre-requisite virtual identity, and calculate data sources
- Step through each page of the form, performing validation along the way, and re-calculating default values as needed
- Submit the completed form
- Trigger workflow with form data as context
- Process action fixtures to create or update objects in external systems, or pass data on to an enterprise workflow engine
A service form is activated by visiting the URL of the form, which activates the form by POSTing to a REST endpoint. A form can be referenced by its guid id or by name.
When a form is activated, depending on configuration and URL parameters it may load a virtual identity object to use as a data-source for pre-populating labels and inputs. This may be used to create e.g. an account update form. Forms may also have data sources to populate dropdown, select and checklists, auto-completes, or just calculate default values. A data source can be a fixed list, or generated with a database query.
Once the pre-requisite data is calculated the initial form page is returned to the requester and rendered.
A form may be broken into multiple pages, sections, and rows. Validation and re-calculation of default and visible values is performed both browser and server side each time a page is submitted.
A form may be evaluated for workflow processing after any submission, but typically workflows should only be triggered for completed forms.
Typically a service form triggered workflow will use a Fixture Step workflow activity to perform update, create, or delete operations on external systems such as MIM Portal, AD, or SQL databases.
Service Panel hosts a separate HTML front end from Identity Panel which is served at the alternate URL. This application uses a Google Material Design UI framework, but theme colors, application, logo, and name may be customized through Service Panel settings.
Service Panel supports dark and light color themes. Advanced layout customization is possible via the addition of a custom CSS file.
Track & Trace
The Service Panel Track & Trace feature is independent from most other Service Panel features. As objects are saved by Panel Service, they are evaluated by a workflow trigger. If the trigger matches a track & trace sequence is queued. Track & Trace operations are evaluated every ten minutes by the Web Maintenance Service.
A Track & Trace sequence must have at least one step, and each step in the sequence can have its own time delays and conditions for success and failure.
Each Track & Trace step transitions through the following states:
- Not Started – evaluation has not started due to an initial wait delay
- Pending – evaluation loop has started, but critical time threshold not reached
- Warning – success criteria not met, but warning time threshold reached
- Success – result query matched and success criteria met
- Fail – result query matched, but failure criteria met
Each time a track & trace step transitions from one state to another, a workflow step sequence may be triggered.