Skip to main content

Journey Policy and Entity Data Overview

Policy & Relationship to Entity and Journeys​

In the Fenergo SaaS platform a Policy is what clients create to define the Data Points / Ownership Details / Documentation they want to gather as part of their Client Lifecycle Management process. To draw a comparison against traditional system design, a Policy can be thought of as a Data Model or Object Model. In the same way as tables on a Database or objects in code are used to represent real world equivalents within a software system a FenX Policy represents the data which FenX users record when engaging with their clients.

The comparisons with traditional Databases or Objects stop there. The Policy Functionality in FenX is a Framework that allows clients to create and adjust in accordance to their business requirements. It is both flexible & configurable in a fluid way that traditional data structures are not.

Policy Configuration Functionality​

  • A Policy can created in the UI (Traditionally done as part of FenX project aligned to client Requirements) by clients themselves, SI partners or Fenergo Professional Services.
  • A Policy can also be created via the APIs which would allow clients to operationalise the deployment of new policies in line with changes within an organisation.
  • A Policy goes through a simple lifecycle of "Create Draft" -> "Submit for Approval" MetaData End--> "Approve" at which point a policy is considered as "Published".
  • Once live and Published the latest version of the policy is what is used inside the various tasks / stages of a Journey to present forms to users (or via API calls).
  • The Data gathered inside a journey is stored along with an Entity inside a Document DB (In FenX this is Dynamo DB - A NoSQL Document Store Database)

FenX Policy Composition​

The Policy itself is comprised of elements as illustrated above and the composition is designed specifically for the business activity of "Client Lifecycle Management" which is why there are dedicated sections for "Data, Document Requirements and Ownership details".

A FenX Policy is also "Legal Entity Centric", meaning the root Object is intended to be an Entity under Management (typically a client of a an institution or related party). Within the Data section there are also "Data Groups", which can be thought of as "Sub-Entities". These can relate to the Root in a 1:1 or 1:M.

Data Group Example​

If a Company is being Onboarded, ordinary data points such as Name, Business Market, Size etc... are gathered. Also something like addresses are gathered. A Company might (and typically does) have several addresses and the data points in an address are modelled inside a data group one time. Multiple "Addresses" can be added to the Root Entity as part of the information gathering. The definition of an "Address" as a "Data Group" keeps the data structured and clean.

As can be seen below - the Difference between how Data is stored in a "Flat" Structure on the Left, versus a "Relational" Structure on the right. If a requirement to add a new address occurs, it can be done in a relational structure using an Address Data Group Instance on the right, where as in a Flat Structure it would require a Data Model Change.

FenX Journey​

In the Fenergo SaaS platform a Journey is how our clients model their business processes. Through the User Interface (And Via APIs), the components of a process can be arranged, grouped and structured to reflect the complex business steps required by clients in how they operate their CLM activities.

In the same way as policies are fluid and configurable, Journeys can be versioned, changed and published. Any easier way to think about a journey in terms of traditional software systems is as a workflow.

A Journey consists of:

  • Top Level Journey Details
  • Within a Journey there are Stages
  • Within Stages are Processes
  • Within Processes there are Tasks
  • From within Tasks -> Areas of a Policy are Targeted (For presentation and Collection)

FenX Journey to Policy Relationship​

Once modelled and configured, a journey instance is created to gather the data outlined in a policy. As mentioned, a journey is a workflow, in FenX the workflow functionality is built upon "AWS Step Functions" More Info.

The final way to think about how all of this interacts is as follows:

  • A Policy defines "What" data to capture
  • A Journey maps out "How" to capture that data.
  • Lastly a "Legal Entity" is the record where the ACTUAL information is stored.