Process

Processes provide a way to model business rules and add automation to ContactsLaw.

A process is a collection of rules which run in response to some event, or when started manually. These rules pertain to a particular subscription, workgroup and/or document type.

Examples of processes include:

• Creating tasks to catalogue documents after they are uploaded
• Generating documents when a matter progresses to a certain point
• Periodically checking whether an invoice has been paid and sending reminders to the debtor

Properties

Processes have the following properties:

• Description
• Category - Freeform text used to group together logically-similar processes.
• Optional design documentation
• Active/inactive - Whether new instances of the process can be started. Set to inactive when a process is no longer in use.
• Treat as activity - Whether the process is presented as an indirect activity (allowing users to start and create instructions for it). Not applicable if the process starts automatically.

Assets

Main page: Asset

Similarly to how they are used in document templates, a process defines a set of assets that represent the resources it can refer to.

One important difference is that processes can also create new resources (e.g. contacts, matters, tasks, etc). This means that a particular asset may refer to an existing resource, a definition for a new resource, or a combination of both. It also means that the number of resources a particular asset resolves to may change while the process is running.

The other main difference is that processes do not have separate definitions and configurations. Unless the resource represented by an asset can be inferred when the process starts, the asset will initially be empty. Resources are explicitly added to assets using rules.

Assets have the following properties:

• New Indicator - Indicates that the asset will be used to create new resources. This prevents resources from being inferred when the process starts.
• Required Indicator - Marks the asset as mandatory. The process will not start unless the asset resolves to at least one resource. The process can be designed on the assumption that the asset won't be empty.
• Multiple Indicator - Allows the asset to be resolved more than once. If absent, this allows the author to avoid making provisions for multiple values.
• Properties (custom assets only) - Specifies the default value for each property of a custom asset. This allows rates, charges and other variables to be defined in a single place.

Entry Points

Entry points describe how to start a process automatically. If a process has no entry points, it can still be started manually.

They consist of:

• An asset of a particular type that is resolved when the entry point is triggered.
• An event that may occur on the type of asset (e.g. when a document is uploaded).
• A condition that further quantifies the event (e.g. for a particular document type). This is optional; however, if the process is associated with a particular workgroup or document type, you may not be able to change the condition.

A process may define several entry points, allowing it to start in different circumstances. Each time an entry point is triggered, a new instance of the process is created - even if it is already running with the same resource(s).

Rules

Rules contain the logic of a process.

There are several types of rules:

• Unconditional - performs a sequence of actions.
• If-Then-Else - tests a condition and executes a different sequence of rules depending on the result.
• Switch-Case - executes the sequence of rules that correspond to a particular value for an expression.
• While-Do - repeats a sequence of rules for as long as a condition remains true.
• For-Each - repeats a sequence of rules for each value in a set.

Rules can be nested to model complex requirements. Together, they form a flow chart that can be used to follow the progression of the process.

Conditions

Conditions are tests (typically expressions) that evaluate to either "Yes" or "No"; and are the basis for making decisions in processes. They can be combined using Boolean logic ("and", "or").

Actions

Actions describe work to carry out within ContactsLaw.

Types of actions include:

• Adding existing resources (e.g. contacts, matters, etc)
• Creating new resources
• Updating resources
• Prompting members (asking questions or sending messages)
• Waiting for tasks to be completed, or until a particular date/time
• Showing interactive forms

Actions may cause the process to pause, pending some requirement; when met, a job is scheduled to resume the process.

Forms

Main page: Workflow:Form

Processes typically run autonomously; however, they may also include interactive forms. Forms pause the process and are sent to users for completion; after which the process resumes.

Forms can be used to:

• Present information added/created by the process so far
• Collect information for use in subsequent rules
• Execute rules that update the form itself

Forms do not directly create/modify resources in ContactsLaw; instead, they keep track of pending changes to assets. These changes are only applied when the form is completed. This makes it possible for users to save their progress and return to the form later, or to cancel and discard the changes.

Instances

Each time a process starts, ContactsLaw creates a new instance of the process.

Instances of processes have the following properties:

• Information about how the process was started
• A list of resources that were resolved for each asset
• The current progress through the rules
• Whether the process is waiting on any tasks or prompts

Members can see a list of processes that they started, with the option to abort a particular instance if it needs to be stopped prematurely.