Each business service can have a combination of configuration and reference data defined, which controls how it progresses through the workflow and what outcomes it generates. Some of these elements are established by the configuration of the service, they are defined at the design time and cannot be changed once they are deployed. Other elements can be maintained through a user interface, as typical ‘reference data’. This is reflected below in the column "Changeable?": if it is set to Yes, then the value of the setting can be changed post go-live and this would alter service behaviour immediately. Settings are broken into six sections, if the entire section is set to Yes, then all settings inside it must be provided.
S01 Transaction settings
| # | Setting | Changeable? | Description |
|---|---|---|---|
| S01.1 | Service code | No | Unique system name that is assigned to each business service. |
| S01.2 | Service form heading | No | This item defines the name of the business service online form to be displayed when entering data into the online form or viewing its details. It can be different from the filing name, name of the review task and name of the activity associated with this service. This heading will also be used when displaying the business service instance via Filing tab / All sub-tab and on presenter’s dashboard. |
| S01.4 | Privacy of service instance | No | Options: filing privacy levels configured for the project (e.g. Public, Private, Internal). This item specifies the default privacy level of the service instance, i.e. what permissions do the users need in order to see the service instance in the entity ‘Filings’ tab / ‘All’ sub-tab tab of the entity. |
| S01.5 | Service view | No | This item defines the content of the service form when it is viewed as read only – from entity ‘Filings’ tab / ‘All’ sub-tab – from the presenter’s Dashboard (things in progress, past activity) – from the Work queue (task details) |
| S01.6 | Entity extract | No | This item defines the content of the entity snapshot that is viewed alongside the service instance (Note this is the same view for all business services relating to the same entity type). E.g. when viewing the service instance details from the activity tab or from the work queue task, Verne has an option to show full snapshot of entity data before or after the change introduced by the service. |
| S01.9 | Concurrency | No | The below list of settings determines how Verne should handle cases where multiple users attempt to initiate, progress or complete maintain business services on the same entity, where data conflicts can potentially occur. Refer to the section Merging Changes if you wish to understand more on how Verne handles this at a core level. |
| S01.9.1 | Outgoing merging and conflicts | No | Options: – Applicable if this business service introduces changes to the entity data. When completed (activated) it can cause merging and therefore conflicts with other in-progress business services that have requested to update data elements of the same conflict levels. Specify the conflict levels for each data element that can be affected by this service. Refer to ‘Conflict levels’ section on the Merging Changes page. – Not applicable if this business service does NOT introduce any changes to the entity data, for example this is usually the case for lodge document services and for all ‘create’ business services. |
| S01.9.2 | Incoming merging and conflicts | No | Options: – Applicable – conflicts possible if this business service introduces changes to the entity data. While the business service instance is pending, it will be a target for merges initiated by other business services on the same entity get completed (activated). Merges could create conflicts when data elements of the same conflict levels is updated in both services. Conflict levels are same as the above setting. – Applicable – conflicts are not possible if this business service does NOT introduce changes to the entity data, for example this is usually the case for lodge document services and for all ‘create’ business services. However any ‘maintain’ service will still be merged into as it contains the full snapshot of the entity data, however no conflicts would ever occur. Note, the incoming merges can originate from other business services activated on the same entity, as well as the same service instance being concurrently edited by different users. This is related to the second level of concurrency (i.e. ‘Service transaction’), Verne behaves in the same standard way for all services so there is nothing we can configure on service by service bases. |
| S01.9.3 | Concurrent service instances | No | Are multiple in-progress service instances of this type allowed on the same entity? This setting determines the behavior for the smart service feature that ensures user is aware of other in-progress instances of the same service and prompts or forces user to continue with one of them. Options for smart service setting: – Not applicable – ‘create’ services do not need this setting – Allowed, no checks Note, there are more options on the road map. Also use this setting to turn on ‘Concurrency lock down’ – refer to Concurrency lock down page |
S02 Filing settings
If filing required to be generated for when this business service is approved then settings in this section must be provided for each of the filings associated with the service. Note, service can generate zero, one ore more filings. Where more than one filing is to be generated, each filing must have its own set of the below items.
Correct the register services generate notice of rectification filings, one filing per transaction. It is not possible to generate more than one filing per one correct the register transaction.
| # | Setting | Description |
|---|---|---|
| S02.1 | Filing code | Unique system name that is assigned to the filing generated by each service. |
| S02.2 | Filing name | This item defines the name of the filing to be displayed on the Filings tab of the entity. |
| S02.3 | Privacy of filing | Options: filing privacy levels configured for the project (e.g. Public, Private, Internal). This item specifies the default privacy level of the filing, i.e. what permissions do the users need in order to see the filing. |
| S02.5 | Filing body | This item defines the content of the filing: – Data elements to be included in the filings – And presentation of the filing Data elements included into the filing body determine the filing scope and conditional generation: – if user updated at least one data elements listed in the filing body, then filing will be generated (unless it is removed via CTR) – if user did NOT update any of the data elements listed in the filing body, then filing is NOT generated – if user updated data elements listed in the filing body as well as some other data elements not listed in the filing body, then the filing will be generated but its body will only include changes to the data elements listed in this setting. All other changes will be ignored. In a simple scenario where a service form is reflected one-to-one in the filing, this setting can simply state “Filing contains all data elements from the online service form presented in the same order using their view settings”. View settings for each data element must be documented separately and include the following: – View label – is the display label for this data element (which might be different from the label used in Edit mode) – Form component View mode – is the documentation describing how data is presented in the view mode (e.g address fields are concatenated and presented in one line) – Privacy level – is the visibility setting (refer to Data privacy levels) – Condition – is the common conditional display logic In the more complex scenarios, where a filing includes a subset of the service form data elements or where it displays additional data elements that are set on service activation and not directly entered by the user, consultants must provide a list of data elements to be included into the filing body and the order they must be displayed, also any additional help/static text, section heading etc. that are not found on the service form, must be described. |
S03 Fee settings
This item specifies whether the service requires fees to be paid. Different fees can be defined for:
- Different submission channels;
- Different people submitting the service – internal vs. external for example;
- Original submission or resubmission.
Fees must be configured for this service using fee configuration functionality and then referenced in the service configuration. Several business services can re-use the same configured fee, in this case, changes in the details of that fee would affect all services that use it. If service does not have any fees associated with it, it could still be an option to define a fee and set its amount to zero, this will allow for an easy way for the registry staff to introduce the fees at a later stage.
| # | Setting | Changeable? | Description |
|---|---|---|---|
| S03.1 | Fee definition | Yes | List of all fees associated with the service submission and conditions that make the fee applicable (if it is conditional). For each fee specify: – Code – Name – Amount – Currency – Description |
| S03.2 | Fee definition for resubmission | Yes | This item specifies whether the service requires fees to be paid when the service is resubmitted. If the fee is to be paid on resubmission, then associated fees must be configured for this service using fee configuration functionality and then referenced here. The ability to return the service is configured in the task configuration by enabling “Revise” action. |
S04 Workflow settings
| # | Setting | Changeable? | Description |
|---|---|---|---|
| S04.1 | Workflow definition | Yes | Workflow for a business service must be configured using service workflow configuration functionality and then referenced here as a service configuration setting. Workflow definition would determine the exact life-cycle of a business service instance (i.e. what statuses it travels through) and what events, user-triggered and system-triggered, would transition the service through its life-cycle. Several business services can re-use the same configured workflow, in this case changes in the details of that workflow would affect all services that use it. Normally all business services would share the same workflow definition since there are a number of parameters that can be defined in the settings below that can influence the flow. |
| S04.2 | Allow draft | Yes | Options: Yes/No This section determines if an instance of this business service can be saved by a presenter as a draft using ‘Save and Exit’ option. It is recommended to enable this option at all times for services where user has to perform some data entry. If a business service does not require any data entry then it does not make sense to enable ‘Save and Exit’ option, for example, a business service where information needs to be simply reviewed and confirmed. If this setting is set to ‘Yes’, then the below two settings must be configured to set the expiry timeframe. |
| S04.2.1 | Days to expire a draft | Yes | Options: Does not expire OR if it does specify a number of working or calendar days. This section determines if draft instance of this business service is going to expire when it is saved for later but not completed by the presenter in the outlined timeframe. If the form is not completed within the configured timeframe then it will be expired. Expiry of the service is enabled by the workflow engine. Note, drafts do not necessarily need to expire, however it is recommended for the projects to configure expiry timeframes to avoid cluttering of user’s dashboards. This item defines how long the user has to complete and submit the business service that has not yet been submitted. This applies to the service instance in any status prior to submission, e.g. Draft for the standard workflow. The following fields are set for the service transaction when the user selects to save a service as a draft: – Service expiry due date (DueDate) = <Service created date>+<S04.2.1 Days to expire a draft> – Days to expiry (DueDays) = <S04.2.1 Days to expire a darft> |
| S04.2.2 | Days to send draft expiry reminder | Yes | Options: Does not expire OR if it does specify a number of working or calendar days. This item defines after how many days since the user started the service that a warning communication will be issued to the user. In the event that the user saves a partially completed form, then a warning will be issued to them advising them that the service requires submission soon. Setting this to 0 days will result in a warning being sent as soon as the service expires. This applies to the service instance in any status prior to submission, e.g. Draft. The following fields are set for the service transaction when the user selects to save a service as a draft: – Service expiry reminder due date (WarnDate) = <Service created date>+<S04.2.2 Days to send draft expiry reminder> – Days to expiry reminder (WarnDays) = <S04.2.2 Days to send draft expiry reminder> |
| S04.3 | Review required | Options: Yes/No This section specifies whether the service requires internal review before it can be applied to the register. If set to Yes, then associated task(s) must be configured for this service using task definition functionality and then referenced in the service configuration settings below. Several business services can re-use the same configured task, in this case, changes in the details of that task would affect all services that use it. A service can be associated with multiple configured tasks and the specific task is selected based on the condition, e.g. company registration service can generate a different task depending on the region that the company belongs to. Also, a service can generate a task if a certain condition is met or can be auto-approved, e.g. review of the company registration is only needed when the form contains a foreign address. | |
| S04.3.1 | Task and auto-approval details | Yes | Options: List the task definitions associated with this business service and conditions for when each of the task definitions applies. If there is a scenario when a business service is auto-approved, then the condition must be described as well. One business service instance can generate ZERO or ONE task. Task selection conditions must be mutually exclusive so that only one task is selected at all times. In configuration this will be ensured by setting ‘precedence’ order, the first condition to be met fires a task, all other conditions are ignored. For example, the majority of services will have the following setup: Example 1 Line 1: Task definition = Auto-approved / Condition = Not Applicable (this means that business service is never going to be auto-approved) Line 2: Task definition = Task 1 / Condition = Unconditional (this means that business service will always use Task 1 definition) Example 2 Line 1: Task definition = Auto-approved / All addresses are local Line 2: Task definition = Task 1 (Fraud prevention team first) / Condition = At least one address appease on the back list Line 3: Task definition = Task 2 (processing team first with option to assign to fraud prevention) / Condition = At least one address is overseas and no blacklisted |
| S04.3.2 | Task details for resubmission | Yes | Options: List of task definitions and conditions when each of the task definition applies. If there is a scenario when the task is auto-approved, then the condition must be described. E.g. If the task definitions above enable the ‘Revise’ action, then this setting must be specified. This section specifies whether the service requires internal review when it is resubmitted. E.g. the service can be resubmitted after it was returned for revision by the internal reviewer. This can happen multiple times. Review settings for resubmission can be exactly the same as “S04.3.1” submission settings or can be different. |
| S04.3.3 | Days to expire when returned | Yes | Options: Does not expire OR if it does specify a number of working or calendar days. If the task definitions above enable the ‘Revise’ action, then this setting must be specified. This item defines after how many days the presenter is expected to have completed the revision and resubmitted the business service. If the form is not revised and resubmitted within this timeframe then it will be expired. This applies to the service instance in in-progress statuses after review, e.g. Revise. The following fields are set for the service transaction when an internal user selects revise action on the task: – Service expiry due date (DueDate) = <Service returned date>+<S04.3.3 Days to expire returned service> – Days to expiry (DueDays) = <S04.3.3 Days to expire returned service> |
| S04.3.4 | Days to send expiry reminder when returned | Yes | Options: Does not expire OR if it does specify a number of working or calendar days. If the task definitions above enable the ‘Revise’ action, then this setting must be specified. This item defines after how many days since the service was returned to the presenter for revision that a warning would be issued to the user. Setting this to 0 days will result in a warning being sent as soon as the service expires. This applies to the service instance in in-progress statuses after review, e.g. Revise. The following fields are set for the service transaction when an internal user selects revise action on the task: – Service expiry reminder due date (WarnDate) = <Service returned date>+<S04.3.4 Days to send expiry reminder when returned> – Days to expiry reminder (WarnDays) = <S04.3.4 Days to send expiry reminder when retuned> |
S05 Document receipting settings
| # | Setting | Changeable? | Description |
|---|---|---|---|
| S05.1 | Business service name for document receipting | No | An alternative business service name can be defined. This allows for additional information such as form numbers or identifiers to be included in the name displayed in Document Receipting. |
| S05.2 | Form name for legal filing document upload | No | This item specifies the name of the document/form that represents an online form of this business service, this document will be displayed as an upload when receipting the bundle. |
| S05.3 | Fee definition | Yes | If different fee amount is to be charged for paper submissions, then state the fee code here. Note: typically jurisdictions charge a higher fee for paper submissions to encourage online submission. |
| S05.4 | Data entry task definition | Yes | When a paper form is receipted that represents the original submission, a special type of task is created for internal staff to do the data entry. This associated task must be configured for this service using task configuration functionality and then referenced in the service configuration. Several services can re-use the same configured data entry task, in this case, changes in the details of that task would affect all services that use it. |
| S05.5 | Data entry task definition for resubmission | Yes | When a paper form is receipted that represents the resubmission of the previously returned document receipting submission, a different task can be created for internal staff to finish the data entry. It can be the same task as setting S05.4. |
S06 Watchlist settings
If watchlist required is set to Yes then settings in this section must be provided.
| # | Setting | Changeable? | Description |
|---|---|---|---|
| S06.1 | Watchlist event name | No | Name of the watchlist event to be displayed when this service is activated on the entity. |
0
