Service Panel forms by themselves are data collection methods in a vacuum. Nothing is done with the data unless it is handled by a workflow.
Workflow Triggering
Workflows for a form are evaluated on EVERY SUBMIT, regardless of whether the form passes validation, or even if a multi-page form is on the last page. For this reason its critical to decide if your workflow should trigger when the form is completed, or beforehand (e.g. to send an anonymous cipher link, or saved-for-later link).
Best practice is to create a separate Workflows provider just for Service Panel actions so that it may be version controlled independently from other Identity Panel workflows. Likewise you should create a MIM DevTest Project dedicated to Service Panel actions (e.g. SP Workflows and SP Actions).
To trigger a workflow when the form is both finished and valid set the Workflow Trigger Type to "Service Form". The trigger rule should consider both the Name and Completed property (which is set to a timestamp when the form is valid and complete). Take care that you get the correct Name value and not a Label value, as labels may be localized:
And(Name == "EditUser", Completed)
To trigger a partially completed form simply change the expression:
And(Name == "EditUser", Completed == null)
Once a workflow is triggered you may use any workflow engine steps, although the most commonly used are email notifications and MIM Test Fixture Steps.
Binding a Fixture
The most common action requirement is to write a change out to a directory system. This is done using the MIM Test Fixture Workflow step. With this workflow step you can pluck any shared fixture from any MIM Test project (although for consistency you will want to separate test and operational projects).
Running a fixture from a workflow has a couple differences compared to running from a test.
- All fixtures referenced by a workflow will run on the Panel Service(s) that the workflow is assigned to. Any prefererred server setting on the fixture itself will be DISREGARDED
- Values are passed from the workflow context to the fixture using the
Memo("name")
function. The Memos are defined on the workflow step, and they are all available to the fixture. The Memo Scope is DISREGARDED. Scope is a required field for memo settings, but it does not matter what it is set to.
Typically when binding a Service Form to a fixture, you will create a single Memo called "Data". with a templated rule of [Data]
. This will pass the entire form submitted data to the fixture, where it can be accessed by templating rules e.g.
[Memo("Data").PageName.InputName]
The exception to this pattern is ANY encrypted value. Encrypted values require special handling so that the fixture can work with the plaintext, but the value is redacted from any history elements.
Each encrypted form field should be bound to it's own memo rule:
e.g. Name: Password
Value: [Decipher(Data.General.Password)]
NOTE: The Decipher function does NOT return the plaintext of an encrypted value. Instead it returns a special templating value in the form "[ec:<ciphered data>]"
. The workflow engine in Panel Service then converts this value to plaintext right before passing it to the fixture, then redacts it from the workflow data before saving the history object.
Comments
0 comments
Please sign in to leave a comment.