Rulestar Product Overview

This article provides a summary of some of the key areas to help you get started.

Rulestar’s document automation technology is a market-leading platform born out of a need to automate complex documents (i.e. documents with complex logic determining their content) without using a scripting language.

There are two critical elements to automating a document with Rulestar:

  1. creating a questionnaire using our online smart form builder, and

  2. mapping logical rules to connect the form responses to content stored in Microsoft Word.

 

The Builder

The "Rulestar" no-code visual builder (the Builder) is the core of Rulestar's unique automation platform. It enables you to create a questionnaire that functions as a sophisticated yet simple decision tree, taking end-users down one of the numerous possible paths depending on the answers given at each junction.

 

Inputs

There are many different input types, reflecting the spectrum of data that would typically be acquired in assembling a complex legal document. For a comprehensive list of all the field types, click here.

Each field type has specific validation rules, meaning that end-users must input valid data before submitting their answers. These data are used in the logical decision-making process, both within the questionnaire and in the document assembly process.

 

Adding Guidance

The platform also enables builders to add rich text fields into the online forms for displaying HTML and other web content on screen. This is useful for adding guidance and commentary to assist end-users in making choices and completing the questionnaires.

 

Efficient Construction

Questions are arranged into sections that have a common logical thread (i.e. there's no need to repeat the same logic for each field within a section), making it especially easy for builders to organise the questionnaire into a logically concise and visually pleasing format. The figure below shows an example of a section with input fields and a rich text field containing guidance.

 

BuilderSection

 

Logical Flow

By default, all the fields in the Builder would be displayed to the end-user in the questionnaire, but logic can be easily attached to a section or field to make its visibility conditional on earlier answers.

These logical rules are built with ease using our graphical logic builder: no coding or scripting is required. The graphical logic builder allows for the easy construction of complex logical rules using logical operators and expressions. Rules can have unlimited complexity, referring to multiple inputs and using nested sub-rules. Logical expressions are built with just a few clicks, including operators such as:

  • equals;

  • does not equal;

  • contains;

  • does not contain;

  • is answered;

  • is not answered;

  • numerical comparisons such as greater than, less than, etc; and

  • date comparisons.

 

Mapping the Questionnaire to Document Content

Ranges/slices of content within Microsoft Word can be easily mapped to answers from the online questionnaire. The key to successful document automation is understanding and organising the conditions under which the variables (i.e. answers to the questionnaire) will combine to lead to differing document outputs.

The mapping process is split into four distinct processes:

  1. logical rules – building logical rules that act as conditions for content to be included in, or excluded from, the resulting document;

  2. tagging content – applying 'names' to the ranges of conditional content inside Microsoft Word to link them to those logical rules;

  3. merge fields – merging answers from the questionnaire into the document (e.g. names, case details); and

  4. replacement rules – find and replace actions to automatically correct user errors and apply final content modifications before the generation of the document.

The Builder also includes tools to analyse and validate the mapping structure, with any inconsistencies in the mapping being automatically detected and flagged for the builder's attention.

 

Merging Content From the Questionnaire Into the Document

To merge answers from the questionnaire into the document (e.g. names, addresses and other details), use the MS Word Add-in. Content that can be merged into the document includes text and images.

 

Named Ranges

We call the ranges/slices of conditional Microsoft Word content Named Ranges. A Named Range can include any content, from as little as a single character to multiple pages spanning tables and images.

Each Named Range is tagged with a name that corresponds to a logical rule. These logical rules are built using the same graphical interface, and following the same process, as for fields in the questionnaire. The concept behind this approach is simple and powerful:

  • true or false – if the relevant logical rule validates as true, the content will be included in the resulting document; if false, the content will be removed; and

  • scalable and efficient – the same name can be applied to multiple ranges, but the relevant logical rule only needs to defined once, meaning that extensive and highly complex documents can be handled with ease.

The image below shows examples of some Named Ranges.

 

Tagging Conditional Content in Microsoft Word

Once the range names and logical rules have been defined in the Builder, we simply need to tag the related content in our 'library' or 'bank' of content, which is stored in Microsoft Word. Tagging Conditional Content is also done using the Word Add-in.

There are important reasons why this is preferable to marking ranges of conditional content with text:

  • no mutually exclusive logic – they cannot be overlapping, meaning that you won't accidentally apply two mutually exclusive tags on the same content; and

  • keeping the content clean and clear – they don't form part of the text content of the document, meaning that you won't confuse the tags with the content, which is a major issue with text markers. With content controls, the range markers can also be toggled to be hidden or visible, which is useful for reviewing and formatting the content.

 

Replacement Rules

Replacement Rules are essentially 'find and replace' actions that can be run after the document content has been compiled and before the final document is saved. These rules can be conditioned on logical criteria in much the same way as to form fields and Named Ranges. Replacement Rules are a powerful tool for:

  • correcting common errors that can arise from free-text inputs (e.g. avoiding a double full-stop); and
  • modifying the content of the output document, such as changing the pronoun for a party to court proceedings to "appellant" or "applicant" or "prosecutor" under various conditions.

 

Error Prevention and Testing

The platform includes many tools that compare the online form and template to detect and flag any errors or anomalies automatically. Those potential errors are brought to the builder's attention for correction.

Once all errors have been fixed, it's time to test the solution from the front end. This is done by previewing the form within the Builder or embedding the form in a website.

 

Front-End Interface

In the image below, you can see an example form previewed in a web browser. It's worth pointing out the following features of Rulestars front-end interface:

  • customisable styling – the appearance of the form is highly customisable: colours, fonts and many other elements can be changed to match your desired branding/styling and the branding/styling of your customers;

  • smart navigation – you'll notice that there's a navigation panel on the right. This shows all the navigable sections in the form while the user is engaging with it. This is a "smart navigation" system in that it enables the user to jump backwards and forwards to review and amend answers, regardless of which of the many hundreds or even thousands of possible paths the user might take through the form, dynamically adapting to the user's choices;

  • field validation – fields will switch to an invalid state (e.g. glowing red) if users input invalid data or attempt to skip required fields;

  • address lookup address fields have a built-in 'lookup' function for all Australian addresses; and

  • saved contacts – party details can also be stored for future use using contact mapping, both within the form and across other forms, if the user chooses to do so.

For a more thorough examination of how our forms work in the front-end, you can try one of our demonstration documents here. You'll also be able to produce a fully formatted document in PDF version (speak to us separately to get the Word version). This demonstrates the automatic cross-referencing, error correction and other intelligent features of the output document.