Post processing with Forms

Post processing occurs when a submitted form invokes a separate, user-defined process after submission. Processes are used for any kind of update to user-defined data based on information provided by a user. For example, you have an annual verification process for your members. Use the post-processing feature to generate a new annual verification record for a member, so that their submission status for the prior year is reset to its initial state. Post processing displays a custom status message, designating success or failure after the process has been executed.

Post processing operates in one of the following ways:

  • Process selector - Selects the page from where the Form script deploys. This process checks the existence of the targeted page and/or procedure.
  • Process parameters - Identifies and passes two or three parameters when invoking a process that then update the user defined data.

Post processing works differently depending on how a client is hosted:

  • Cloud-hosted clients - A successful form submission invokes a script page in iMIS to execute a process using the REST API.
  • On-premise clients - A successful form submission invokes either a script page or a SQL stored procedure.

Process parameters

In order for Post processing to execute properly, the following parameters must be included in the form in question:

  • ID - The ID of the user who submitted the form, or the ID of the on Behalf of user. This field supports a maximum of 10 characters.
  • Ordinal - The ordinal or sequence value of a multi-instance record updated by the user for a selected MI source. If this option is selected, the Multi-instance source must also be defined. This field supports integers only.
  • FormName - The name of the form in question, as defined in the Form library.

Note: All parameter values are passed to the post processing script, however the value of Ordinal may be undefined, for example, when the form designer chooses to send only the ID and FormName to the post-processor. In this case, the Ordinal will not be displayed when referred to by the JavaScript method.

Creating Form Builder scripts

A JavaScript function designed to work with Form Builder has the following key attributes:

  1. The JavaScript ID must be:
  2.  <script id="formswebhook"> 
    </script> 
  3. The script must consist of an asynchronous JavaScript function that accepts the following parameters: ID, Ordinal and FormName.
  4. The JavaScript function must return an object consisting of a boolean result and a string message:
    var returnedObject = {result: false, message: "Unknown error"}; 
    1. The returned object's "result" property must be defined on returning from the post-processing function, result=true for success and result=false for failure.
    2. The script can optionally return a detailed message to the form for display in the success or failure message box. The returned object's "message" property may be undefined, null, an empty string, or a defined string constant. This message can be defined by the script and include dynamic information content.
    <script id="formswebhook"> 
    
    async function formswebhook(ID, Ordinal, formName) { 
    
            var returnedObject = { result: false, message: "Unknown error" }; 
    
    // Insert Post Processing Steps Here 
    
           returnedObject.message = "Process success message! ID:" + ID + ", FormName: " + formName + " + Ordinal (if applicable): " + Ordinal; 
    
            returnedObject.result = true; 
    
    // use  returnedObject.result = false; if the process fails 
    
            return returnedObject; 
    
        } 
    
    </script>