Approvals

When designing forms that are to be used with Approvals, it is important to note that certain Form Builder features ARE NOT compatible with approvals as shown in the following table:

Note: An important case is the use of Signup fields and the Create Account options when designing a "Contact creation" form. For approval processes that involve creating an account, the Create Account step must be separate and not require approval. In order for iMIS to properly process an approval form, the iMIS ID must be known and assigned to the account.

Important! Documents (file upload fields) and multi-instance layouts are not supported because they update iMIS directly and cannot be intercepted prior to committal to the database.

By design, Form Builder forms will update your iMIS database directly and immediately. This allows you to make decisions based on data provided by your applicant or stakeholder and present the most relevant content to them. In certain cases, you may wish to prevent any updates from occurring in iMIS until the data has been reviewed by a responsible staff member. In such cases, you can enable the Approval feature of Form Builder to validate form submission before it reaches the database. Here’s how it works:

1. A form or group of forms is marked as Requires Approval in the Form Library.
2. Form submission and presentation appears the same to the end-user as it would for a normal form.
3. Upon successful validation and submission, the database additions and changes that the form has created are paused, awaiting staff approval.
4. Authorized staff visit the Approvals Queue to see pending form submissions.
5. Each submission can be reviewed by staff and either approved or rejected.
   • If a submission is rejected staff would be expected to notify the applicant or author of the form.
   • If a submission is approved then the contents of the form will be processed (staff can exclude some fields if they wish) and any post-processing steps will be invoked.

Note: Keep in mind you can approve or reject submissions On Behalf Of only if the person you are approving or rejecting on behalf of is a user. If the On Behalf Of person is not a user, iMIS will use the logged-in user’s information for approvals.

Form Builder provides you with a dashboard environment to assist you with managing your incoming approvals.

• Submissions in queue represent all of the form submissions that are awaiting attention
• Approvals this month shows a count of all form submissions that have been approved
• Post errors pending show a count of all approved form submissions which encountered processing errors when they were submitted to iMIS. These situations require further staff attention to resolve the problem(s) encountered.

Setting a form to require approval

Setting a form to require approval is done via the Form Library.

Do the following to set an individual form to require approval:

1. Click the edit icon next to the form name you want to require approval for.
2. Click the checkbox next to Requires approval.



3. Click Update.

In some cases, an entire family of forms may need to be treated as an Approval Group. This means that any and all forms in that group require approval when submitted. For example, a long-form application process spanning several forms where you wish to accept or reject the final submission.

Do the following to enable this feature:

1. From Form Builder > Form groups, click the edit icon on the group you wish to approve.



2. Click the Requires Approval checkbox.



3. Click the save icon.

When group level approvals are enabled, each form that is part of the group will show the Requires Approval as locked.

The submission process is managed from the Approvals dashboard. The dashboard has the following features to make this process easier to manage and review.

1. Status – This defaults to the Post Error and Submitted status codes to show you all submissions that require attention. You can also review Rejected and Completed submissions for research purposes.
2. Form – This list shows all of the forms that require approval which allows a staff member to focus on reviewing a specific form.
3. Group – Similar to the above, this shows all of the form groups that require approval and allows you to filter submissions based on Form Group.
4. Submission – Allows you to find a specific submission ID when returning to review an item that has been Returned to Queue.
5. Submitted – this date and time shows when the form was submitted and defaults to the oldest first.
6. Group Approval – this shows forms that are part of an approval group.

Submission review

Do the following to approve a form approval:

1. Click the form you want to approve.
2. Review the following information for accuracy:
   • Update of – a user-definable block of context information regarding the user. This allows you to expose information such as member type, category, join date, disciplinary status, etc. that are relevant to an approval decision. The hyperlink opens a new window on the member's profile so you can do further research prior to making a decision on the submission. The fields shown on this section are controlled via an IQA that you can adjust to meet your needs.
   • Submitted by – an additional user-definable block that displays the information for the account that submitted the form (if it is different than the Update of user). This is also controlled via an IQA.
   • Process History – a system generated information block that records and displays the overall process when a submission is approved and encounters a Post Error.
   • Staff Notes – a free form text field that allows staff to record observations and notes on the pending approval or issues for resolution by a supervisor. Click Save to record these notes.
   • Form Navigation – the Previous and Next buttons allow you to move between submissions rapidly without returning to the Dashboard.
   • Approval Matrix – a formatted summary of the changes generated by a form submission. Fields that were not changed during the form submission are marked in green. Fields that have been changed are marked in red. Each row represents an independent update of data in iMIS. Using the selector control, you can selectively approve or deny specific field updates. For example, if a member is allowed to change their member type on a form but does not meet the criteria for that class of membership then the member type change can be disallowed while other form related changes are allowed to proceed.
   • Approval Controls – the approval controls allow you to selectively perform the following actions:
     • Reject Submission – Rejecting a submission will disallow all of the changes presented by the form. If a submission is rejected you should also take the step of notifying the affected member of the reason(s) for this rejection.
     • Return Submission to Queue – In some cases, you may need to consult with a colleague or wait for additional information before deciding. The Return Submission to Queue option allows your notes to be captured and saved for later review or review by another staff member (if a submission needs to be escalated).
     • Approve Submission – Approving a submission will process the selected updates that you have identified.
     

     Note: Keep in mind you can approve or reject submissions On Behalf Of only if the person you are approving or rejecting on behalf of is a user. If the On Behalf Of person is not a user, iMIS will use the logged-in user’s information for approvals.

   
   

Note: Approving a submission without selecting all of the updates effectively rejects the unselected updates and those changes are neither made in the database nor recorded. Note the rejected changes for feedback or other purposes.

3. Depending on how accurate the form is, click Reject Submissions, Return Submission to Queue, or Approve Submission.

Customizing Submitter Information

The Submitter and Party information associated with a form submission can be controlled by updating the IQAs PartyInformation and SubmitterInformation in the folder $/Forms/Approvals. This IQA defaults to the contact name, ID, Member Type, Category, Email and Company; however, any combination of fields can be deployed as needed.

Note: SubmitterInformation may be applicable if someone is updating On Behalf Of another user, however, if the person submitting the form is one and the same as the person who is being updated then only the PartyInformation IQA will display.

Approval Processing mirrors the form submission process and performs the same functions and actions.

• Each update statement is processed in order and the change is applied to iMIS. The Change Log is updated based on your settings in Panel Designer. The date of the change will be the date that the approval is processed.
• If applicable, the form's post-processing step is also invoked. If the post-processing step returns a message (success or failure) it is displayed at the bottom of the page.

If the form processes normally and successfully the submission status will change to Completed and no further processing is permitted (all Approval Controls are disabled). You are able to search for and review any submission for audit and confirmation purposes as needed.

Normally, the approval process should process updates correctly and completely, however, in rare instances issues can arise that can prevent the successful processing of a form submission. The following are some examples:

• A change to the iMIS database may mean that a field no longer exists.
• A change to the iMIS database may alter a field's type or attributes in such a way that the update cannot succeed.
• The post processing step may fail based on business logic; for example, if a membership application does not meet your approval standards based on a complex formula.
• The post processing step may fail technically due to a system fault or programming error.

If an update should fail for any reason, then this information will be logged to the Process History and the submission will be marked as having had a Post Error.

Note: Once a Post Error is encountered, you cannot resubmit a form submission. Post Errors must be reviewed and resolved directly in iMIS.

To resolve this error, the staff member needs to open the member's record and manually enter the correct information into the appropriate field. Once this has been done, the adjustment should be recorded in the Notes field.

Note: Whenever a Post Error is encountered then the cause should be investigated and resolved as quickly as possible to prevent further submission issues going forward.

Post errors impacting post processing

Normally, the form's post-processing step may also be invoked (if applicable) after all of the form's updates have been applied. Post Processing is aborted if Approvals encounters any Post Errors to allow you to resolve the issues before the Post Processing is invoked.

In certain cases, the Post Processing step may return an error (which would normally be displayed on the form). This is recorded in the Process History and staff will need to intervene in such cases to investigate and resolve the issue reported. This also is tracked as a Post Error that will require resolution.

An alternative to using the approvals feature is to manage submissions through the use of status codes. By marking your form submissions with the status code Unreviewed you can capture data immediately in iMIS and then easily review that submission by performing a simple query on updates where the status is Unreviewed.