Business Rules have several quirky behaviors that will be addressed in a future release. Please read and understand these points before writing your first business rule.
...
The code above makes logical sense but it just won't work. In a nutshell this particularity of the implementation can be resumed explained this way:
The right hand side of an assignment expression resolves to the value of a control passed to a rule when it is invoked. The left hand side uses a reference to the control'.
...
What causes an "Invalid signature detected. Data may have been tampered with" error?
This error message usually displays in multi-step workflows when there is a rule on a subsequent step that executes at form load and updates values inside a signed section in a previous step. Here are some examples and solutions:
Checkbox with Custom Options in a locked Signed Section
Imagine a two step workflow designed with Linked Steps where step 1 contains a Checkbox control inside a section that the user is required to sign, The checkbox has only one option defined in the flow designer. A Business rule is executed when step 1 loads to dynamically populate the checkbox with additional options.
The image shows this scenario in use mode after the rule has executed. Notice there are three options for the checkbox now. The user selects all three options, signs then clicks continue.
The flow is routed to Tasks Lists of users who fulfill the requirements for the next step. When Step 2 loads, the rule is executed again. This combination results in data tampered error.
Solution:
This situation can be avoided by always setting more than one option in the flow designer for any checkbox that will be dynamically populated with a rule.
...
Business rules that change the values of controls inside a signed section may result in the "Invalid signature detected. Data may have been tampered with." error. Rules that "tamper with the data" and invalidate a signature once a section has been signed are no longer allowed. Refer to this topic for the details.
...
Why does the information for the logged in user change when I navigate forward/backwards in my workflow?
Designers can use a Business Rule to initialize fields in the first step of a flow with information about the logged in user. If your flow navigates to a different user/role for subsequent steps, and the user navigates back to step 1, the rule executes again when Step 1 loads, overwriting the information in step 1 with the information of the user performing the subsequent step. This is an important consideration whether your workflows workflow is designed using individual or Linked Steps.
You can improve your rule to account for this. For example, let's say you have a two step flow. Step 1 executes this rule to fill in the First Name, Last Name, Email and the user id into fields named First Name, Last Name, Email and UserID respectively. Note this rule executes when Step 1 loads.
| Code Block |
|---|
if (form.load) {
FirstName.value = _data.getParameter('subject.first.name');
LastName.value = _data.getParameter('subject.last.name');
Email.value = _data.getParameter('subject.email');
UserId.value = _data.getParameter('subject.id');
} |
When user Michael Stewart executes the first step of the flow, here is what you see:
Michael clicks continue and the flow progresses to Step 2 which is designed to be performed by a user with the Manager role, Jerry.
Jerry logs in, and access the task from his Task List. Jerry sees Michael Stewarts information from Step 1:
However, if Jerry navigates back to Step 1, the rule executes again when Step 1 loads and overwrites Michael's information with Jerry's:
To prevent initialized fields from being overwritten if users navigate to a previous step in a flow, you must add a condition to your rule to only initialize the fields if they have not already been initialized when the step loads. Adding the second line to the rule used in this example ensures that initialized fields will not be overwritten.
| Code Block |
|---|
if (form.load) {
if (FirstName.value.length === 0) {
FirstName.value = _data.getParameter('subject.first.name');
LastName.value = _data.getParameter('subject.last.name');
Email.value = _data.getParameter('subject.email');
UserId.value = _data.getParameter('subject.id');
} |
...
} |
The image shows what Jerry sees when he navigates back to Step 1 with the modified rule in place:
You can adapt the conditional statement in this example to fit your rule.