Omni is Simpology Manager's advanced task tracking and communication platform which enables organisations to manage the workflow staging, task allocation and lifecycle of a loan application.
This article is targeted for administrators of the Simpology Manager platform, with a deep dive on how Omni can be configured to suit your organisations workflow.
For general use of Omni as an end-user, please refer to Omni Help Index.
Pre-requisites
Configuring Omni generally requires an 'administrator' set of permissions. If you do not have these permissions, please reach out to your organization's administrator for further guidance.
Overview and concepts
Omni can be understood as the interplay between three key components -
Component | Summary |
1 Application Status | The current state of the application within the loan processing lifecycle |
2 Action Process | The overarching activity being undertaken within the current status |
3 Action Item | The individual task associated with the action process |
An application entering a certain status triggers the overarching action process, which has action items associated with it.
As these action items are completed, the action process becomes complete, which changes the status, which in turn triggers the next stage of action processes.
Real-life Example
Let's take an example of a typical Omni workflow and configure within Simpology Manager.
A broker has submitted an application, and we want to send tasks to a packaging team to review the supporting documents before passing the application to credit assessors for further review.
Using the three components described above, we will need to configure the following items
An application status capturing the state of the application, to reflect that it has been submitted by the broker
An action process, which describes the activity that the packaging team will be performing. When the activity is complete, the application status should change.
An action item, which is the individual task that needs to be sent to the packaging team. This should instruct the packaging team to perform a supporting document review.
Application Status Configuration
First off, we'll want to configure an application status that accurately represented the current state of the application. It has been submitted by the broker, and is awaiting a packaging team's review of the supporting documents. Let's call the status Application Submitted.
We'll start by navigating to https://secure.simpology.com.au/ and logging into our channel.
Using the menu bar, navigate to Account > Setup > Application status setup:
You will then be presented with a list of sub-statuses (a), which are all associated with an overarching primary status (b).
We want our Application Submitted status to reflect that the application is with the lender for review - so we'll put it under the primary status Assessment:
Great - this sub-status already exists!
If we wanted to create a new sub-status within the Assessment primary status, we could press the + Add button. Or, we could edit the existing one by clicking the pen icon on the right.
There's a number of settings we can apply to an application sub-status;
Setting | Description | Example |
1 Name | The name of the status of the application | Let's use Application submitted |
2 Set as approved | Determines whether the current status reflects that the app is considered approved Note - In Loanapp V2 applications, this also makes the 'Submit' button available for this status | The application isn't approved yet, so let's leave this unticked. |
3 Milestone | Determines whether the sub-status is considered a milestone | We'll consider the application submission a milestone, so we'll tick this. |
4 Alert the following management participants | Determines which management participants to alert as result of entering the status.
See Alerts and Notifications for further information on configuring alerts | We may want to send an email confirmation to the broker when they've successfully submitted. So let's enter Broker here.
|
5 Description | A description of what the sub-status represents | We want a brief description of what the status means, so let's use
Application successfully transmitted by the Loan Writer to the lender. |
6 Process on entry | The action process that should be triggered as a result of entering this sub-status | We want to trigger the Review submitted application action process - but we'll come back to this later after we've setup an action process.
|
7 Allocate Co-ordinator | Determines whether the an application co-ordinator should be assigned on entry to this status (see Roles configuration guide) | We may want to assign our application to a specific user to co-ordinate the application in this particular status. |
Advanced | You can skip ahead for this example! |
|
8 Consumer primary status | The primary status as reflected to the consumer (applicant/s) | Maybe our channel is configured to allow consumers to monitor their application - in this case, we could enter:
We've got your application |
9 Consumer sub-status | The sub-status as reflected to the consumer (applicant/s) | Per 8 - we may want a consumer facing name for the sub-status, like
Reviewing your supporting documents |
10 Process on exit | The action process that should be triggered as a result of leaving this status | We typically wouldn't use this setting, as we want action processes to trigger on entering a status, as opposed to exiting.
We may want to use this if we want to trigger two action processes as a result of a single status change. |
11 Back channel trigger code | Associate the sub-status with a backchannel reference number. | We're expecting the broker to submitting the application to trigger this status change, but it may make sense in other examples to associate a sub-status with a backchannel message. |
12 Auto-update application status | The application status will be updated automatically when a back channel message with this trigger code is received.
| For our example, we wouldn't want to change the application status to Application Submitted on receipt of a backchannel. |
13 Auto-complete | The Back channel item will be marked as actioned' automatically, when received. | For our example, we don't want to auto-complete any backchannel items. |
When we're all done setting up the status, we can hit Save.
Great, we've setup the sub-status!
Action Process Configuration
Now that we've setup the application status, we want to setup the overarching activity that will be performed when the application is submitted. We want to generate an activity that shows the packaging team is undergoing an initial review.
Let's navigate to Account > Setup > Action process template setup.
Within, we'll find a dropdown selection of any existing action processes that have been setup. In a default configuration, your channel will already have a number of 'default' action processes which you may choose to use.
We're in luck the Review submitted application action process already exists - but we can add a new action process by clicking + Add button. For this example, we'll select the existing entry. Once again, we're presented with a number of settings that can be applied to the action process:
Setting | Description | Example |
1 Title | The name of the action process | Our action process should reflect that our packaging team is undergoing a preliminary review of the application - let's call it Review submitted application |
2 Description | A brief description of the activity being undertaken within this action process | Per the above, let's describe the activity as
Packaging team undergoing initial checks of the supporting documents supplied by the broker |
3 Action items | The individual action items that should be generated/associated with the action process activity | We want to generate a task for our packaging team - but we'll come back to this later |
4 Is Milestone | Determines whether the action process is a milestone | Similar to the configuration in application status - since the status is already a milestone, we can leave this off. |
5 Generate process report on completion | Determines whether a process report should be generated when the process completes | This is some future functionality that Simpology are working on - watch this space! |
6 Visibility level | Determines the visibility of the action process for parties involved within the application process. Based on a hierarchy from Consumer -> Funder | This setting determines who is able to see that the action process is underway when they open the application in Omni.
In our example, we're happy for the broker to see that we're undertaking an initial review - so we'll set this to Broker |
7 Pass requires | Determines the conditions under which the action process should be considered successfully completed | We want this activity to be considered complete when the mandatory action items are done, so we'll set it to All mandatory |
8 Status after completion pass | Determines the status that the application should change to on completion of the action process | Earlier we mentioned that the completion of an action process should trigger a status change.
Our example wants to pass the application on for credit assessment on completion, so we'll set this to Assessment - Credit review
Don't see the status that you're after? Scroll up and follow the steps to add your new status! |
9 Fail requires | Determines the conditions under which the action process should be considered unsuccessfully completed | We want our supporting document reviews to be mandatory, so let's set this to One mandatory fail |
10 Status after completion when fail | Determines the status the application should change to if the fail conditions (9) are met | Let's say that if the packaging teams review fails, the application should go to an Assessment - Exception review status.
Per 8 - add the status if needed |
Advanced | You can skip ahead for this example! |
|
11 Process rules | Determines the behaviour of the execution of policy & decisioning rules (12) as a result of the action process | Maybe we only want to trigger this action process when certain conditions within our policy and decisioning are met - please refer to documentation regarding Policy & Decisioning for more information. |
12 Process selection rule | Determines which rules should be ran per the setting 11 | Please refer to documentation regarding Policy & Decisioning for more information. |
Once we're happy with the configuration of the action process, we can hit save.
Action Item configuration
Now that we've setup the overarching activity (action process Review submitted application), we now want to setup the action items that get triggered as a result of this action process.
We can stay in Account > Setup > Action process template setup, and either open the Action item tab (a) or click the + icon (b) to add an action item directly to the process we have open:
We can also edit an existing action item by clicking on the entry within the action process (a), or selecting an existing action item within the action item tab (b):
Now that we've got an action item open, again we can see a number of settings that can be applied to action item:
Setting | Description | Example |
1 Action process template | Determines which action process the action item is associated with | In our case, we want to create the action item within the Review submitted application process we setup earlier |
2 Title | The name of the action item | We want to create a task for the packaging team to review supporting documents, so let's call it Review supporting documents |
3 Type | Determines the type of action item that is generated | Our action item is going to be a Task. But if we just wanted to send a simple notification that didn't require any activity, we could select Notification |
4 Priority | The priority of the action item | We want to review the supporting docs quickly, but this is a BAU task - so we'll leave it on Medium |
5 Custom Type (advanced) | Determines the advanced configuration type of the item | This setting determines behaviour in the Decision Support module - we can leave this for now. |
6 Message | The contents of the action items as a text description | This is the messaging associated with the action item. We'll want to describe the task being undertaken, so let's set it to:
Packaging team reviews the supporting document for validity |
7 Checklist (advanced) | A set of checklist items that should be generated when this action item is triggered | We'll undertake the supporting documents review in the Document verification module, so we don't need any pre-defined checklists |
8 Mandatory task | Determines whether the action item is mandatory | Earlier we set the conditions under which the action process passes or fails. We want this task to be Mandatory |
9 For action by team, role or person | Determines how Omni should allocate the task | We want our action item to go to the packaging team |
10 Target team | Determines which team Omni should target the task to | We want our task to go to the Packaging team.
If your target team isn't listed, we'll configure this further down! |
11 Target completion days | Determines how many days this task would typically take to complete | In our example, we want to review supporting documents quickly, so we'll target supporting document reviews to take 1 day before they become overdue |
12 Visibility level | Determines the visibility of the action item per a Consumer -> Funder visibility hierarchy | Earlier, we made the action process visibility to the broker. But perhaps they don't need to know exactly what is being undertaken in the process, so we'll set this to Lender |
13 Action page | Determines which Simpology solution can be accessed via shortcut within the action item | We want to perform a s.doc review in the Document Verification module |
14 Action item rule (advanced) | Determines the behaviour of a policy & decisioning rule configured in 15 | Our task shouldn't be triggered on any policy rules, we'll run it everytime. |
15 Action item selection rule (advanced) | Determines which policy & decisioning rule should be associated with the action item | Our task shouldn't be triggered on any policy rules, we'll run it everytime. |
Once we hit the Save button, we've successfully setup the action item. If we head back to the Action Process tab, our Review submitted application action process should now look like this:
If there's any other action items we'd like to setup, just repeat the same steps above and associate the newly created action item with the action process (setting 1).
Team configuration
Earlier we set the action item to be completed by the packaging team - but let's say that this team isn't setup, or we wanted to modify/create an entirely new team for this particular action item.
Still within Account > Setup > Action process template setup, navigate to the Team tab:
Once again, there are a number of settings we can apply to the team:
Setting | Description | Example |
1 Team | The team that we are editing | This will reflect the title of team team set in 2 |
2 Team name | The name of the team | We're going to call this the Packaging team |
3 Set as default team (advanced) | Set the team for default co-ordinator allocation | Earlier in the status configuration we saw an Allocate co-ordinator setting - Omni will pick users from the the default team. We're not going to use this setting. |
4 Team leader | Sets the team leader | We may want to record the user who leads this team |
5 Team allocation ref (advanced) | Based on advanced behaviour configuration, allocate applications to this team | This is an advanced setting outside the scope of this guide |
6 Members | The members of this team | We'll put John Smith and Joe Bloggs into this team. |
7 Add new team members | Add a new user to the team | Per above |
8 Primary activity and function | Describes the primary focus of the teams work | Let's enter something like Reviews supporting documents |
We've now configured the team - if we need to, we can go back to the action item and make sure it now gets sent to the newly created team.
Tying Application statuses, Action Processes and Action Items
We're almost there! There's just one last step to link this all together.
When we setup the Review submitted application action process, there was a Process on entry setting. Per the definitions provided above, this is the action process that we want to trigger when the application enters this status. We'll need to put our new Review submitted application action process in here, so it gets triggered on entry:
Woohoo we made it! We've now configured the Application submitted status, which will trigger the Review submitted application action process, which has the Review supporting documents action item. The action item goes to the packaging team, and is allocated based on the workload of John Smith and Joe Bloggs.
When John or Joe mark the action item as passed, the Review submitted application action process automatically completes - which then triggers a status change to Assessment - Credit review.
Now we might want to associate a new action process with Assessment - Credit review, and repeat until we've setup the entire application lifecycle from start to finish!