Multi-Publish
The Multi-Publish feature will provide users with the ability to push updates from an open Journey to the verified Entity record at multiple points throughout that Journey. Previously, users were limited to only one update to the verified record, which usually occurred at the very end of a Journey. The reason that this can be limiting, based on feedback from our clients, is that often data captured and reviewed in a Journey may be ready to be verified and shared downstream or included in reporting before a Journey is completed.
An example of this could be local Classification data that has been captured and reviewed and is ready to be sent downstream. As part of this process, users must ensure that all information has been reviewed and they are comfortable with updating the verified Entity record at certain points in time.
Important Notes
- Primary Entity Data only: This scope for this feature will focus on Primary Entity Data which means that the Entity Data for the Primary Entity in which the Journey has been launched for will be candidate to be multi-published. The Related Parties of this entity including association type and entity data can also be multi-published. We will not be looking at multi-publishing Product Data or Deals Data.
- Full Publishing of Entity Drafts: Another important note is that with this change, we will be supporting the full publish of the Entity Draft, meaning that whatever data is captured on the Entity record at a certain point in time in the Journey will be what is pushed to the verified Entity record. We will look at expanding this functionality in the future to allow for partial publishing which will allow for selecting which fields can be published at given times but for the initial release of this feature, the full draft will be published each time.
- Managing Rollbacks: We cannot undo published events, but we can reopen and re-run. What we mean here is that you cannot undo an event for publishing, but users can re-open a preceding task in the Journey and when the Journey progresses to the ‘Publish to Entity’ task, it will simply re-run, incorporating the latest changes in the draft and pushing them to the verified record.
- Reviewing Data ahead of Publishing: To ensure that users are fully aware of the pending changes to the verified Entity record, we have included validation in Journey Builder to ensure that a Conflict Resolution task always needs to be configured before a ‘Publish to Entity’ task. The reason for this is that the user will be made aware of any potential conflicts between what is on the full Entity draft vs the Entity record before making a conscious decision of what data to take forward.
- Multi-Publish is not supported for Parallelism: The ‘Publish to Entity’ task can only be included in a Process where the running order is ‘Sequential’ as well as the Stage running order also being ‘Sequential’. The reason for this is that we need to ensure that the ‘Conflict Resolution’ task always happens before a ‘Publish to Entity’ task. We can however, configure the above in a Stage that is ‘Linked’ to another Stage in that Journey to allow for some flexibility.
- Difference between ‘Publish to Entity’ & ‘Verify Entity’ task types: When the ‘Verify Entity’ task runs in a Journey, we apply hard coded system roles and Statuses to the Entity record based on what has happened in the Journey (e.g. Client role is applied when Client Onboarding Journey is completed). The ‘Publish to Entity’ task will only focus on publishing Entity Data but will not update these system driven roles and users will still require a ‘Verify Entity’ task at the end of their respective Journeys.
- Updating with Parallel Journeys: Currently in Fenergo, we do not compare between Entity Drafts and open Journeys have no way of communicating with one another. However, by implementing Multi-Publish across both Journeys, there will be more frequent updates to the Verified Entity record, which, coupled with Conflict Resolution, can act as the intermediary of communicating between multiple open Journeys.
- Impact to Advanced Search & Reporting: Currently in Fenergo, we do not provide draft values in our Search functionality & Advanced Reporting. This can be frustrating for users as they cannot access information captured on Entities without navigating into the open Journeys to find it. With Multi-Publish, users will be able to update the Verified Entity record more frequently, meaning that they can search and report on the latest changes for Entities.
- Policies coming into scope on the verified Entity record: With Multi-Publish, the whole Entity Draft will be published to the Entity record which means any Policies driven from values captured in the Draft will also show as ‘In Scope’ on the Entity Profile page.
- Limits on number of Publishes to Entity in a Journey: Currently, there are no limits to how many ‘Publish to Entity’ task types included in a Journey.
- Primary Entity Documents: Previously, Document Persistence can only occur across Journeys, when the Document where the Journey was uploaded has a completed "Verify Entity" Task. The "Publish to Entity" Task has an option within the "Select Types to Publish" dropdown of "Primary Entity Documents". This allows for Documents uploaded in one Journey to persist into other Journeys, as long as the Journey contains this Task with the "Primary Entity Documents" option selected, and the Task has completed. For more information on Document Persistence, refer to Managing Documents.
- Publishing Related Party Data Multiple Times: When configured for Related Parties, the task publishes all Related Parties connected to the entity at the point of execution. Partial publishing is not supported. This option can be selected in the task definition alongside the existing Entity and Document domains. This option is intended for journeys where updated Related Party information is required earlier in the process, while still allowing the overall Related Party verification to occur later in the workflow.
Configuring Multi-Publish in Journeys
To configure Multi-Publish in Journeys, users will be required to update their respective Journey schemas with the new task type of ‘Publish to Entity’ as well as the dependent task type of ‘Conflict Resolution’. The order of this must always be ‘Conflict Resolution’ before ‘Publish to Entity’ and to enforce this behaviour, users will see the below validation message of “Conflict Resolution task must be placed before a Publish to Entity task”:
As part of the Journey Configuration, it is recommended for users to keep the ‘Verify Entity’ task within their configuration if they wish to make use of the system applied roles such as ‘Client’. Important note: The system role of ‘Client’ drives additional behaviours in the system such as having a dependency for Ongoing Screening. Another key call-out as part of the configuration aspect of Multi-Publish (as mentioned above) is that users cannot have the Publish to Entity task type in a Process that has a Task Completion Order of ‘In Any Order’ or a Stage that has a Process Completion Order of ‘In Any Order’. They both most be ‘Sequential’. This is because the user must be kept aware of the impact of their change when they are pushing to verified Entity record, meaning that the Conflict Resolution task must be placed before the Publish to Entity task.
Finally, it is recommended to keep the ‘Verify Entity’ task type as part of the Journey configuration to ensure that Document Persistence and system generated Roles are applied where relevant. This task type should be at the end of the configured Journey when all other changes have been made.