Skip to main content
Version: 19

Organization

Introduction​

An organization is the most high-level entity on the platform and represents a customer of Harmoney. All configuration and data of that customer is linked to the organization.

For example:

  • Bank X wants to use the Harmoney platform. A new organization ‘Bank X’ will be created on the platform.

The platform is very configurable and can be adapted to the needs of the organization. Therefore, most configuration of the platform is done on organization level and allows re-usability of configuration on a lower level. The management and configuration of organizations is at the moment done by Harmoney employees.

Since the structure of the platform tries to mimic the real world structure of an organization, most data is not stored on organization level, but on a lower level which we call FSP or financial service provider. Storing the data on organization level would make typical data-separation requirements of large organizations difficult.

Purpose​

Configuration segregation​

Configuration of organization X cannot be shared with organization Y. There cannot be any impact on organization Y, due to a configuration change in organization X.

Configuration maintenance​

The full configuration can be imported and exported with a single click. This makes configuration portable across environments (UAT/PROD).

Configuration management via the admin​

The configuration of an organization can be done via the admin. You’re only able to see and manage the configuration of the current organization. In the future, this will allow us to give admin permissions to users of the organization.

Configuration re-usability​

Multiple FSPs within the same organization can re-use the same configuration of that organization.

Caveat: adapt configuration vs create a new organization

Configuration​

The diagram below gives a first hint as to how the configuration of the application is structured.

There is some shared configuration on application level: this configuration is baked into the application and cannot be modified.

The same configuration elements can be added on organization level and adapted as desired.

organisation_chart

FAQ​

In a shared offering context: single or multiple organizations​

Context: a Harmoney partner wishes to bring a low-budget solution to the market using the Harmoney platform.

Questions:

  • Should we create an organization Partner X or multiple organizations Partner X Customer 1, Partner X Customer 2, etc.?
  • Who manages the configuration?
  • What if a customer requests a configuration change?
  • …

Answers:

  • In a low-budget context, Harmoney should always strive to sell a single configuration-setup to minimize configuration maintenance and ensure scalability for the partner. In order to achieve this, the partner must be the owner of the configuration. Thus, the organization should be Partner X. The configuration can contain different offerings with for example more or less modules. Each offering must be reusable.
  • The partner manages the configuration and decides to either accept or reject change-request from the customers. Changing the configuration impacts all customers.
  • The partner could decide to duplicate the config within their organization if they want to extend their offering. For example: they want to have a configuration with RBA and one without. Both configurations can again be sold to multiple customers and the partner remains owner of the config.
  • It is not allowed to duplicate config within the organization of Partner X on request of a single customer. A new organization must be created for customer 1 to manage their specific configuration segregated from the shared offering of the partner. Pricing should be accordingly.

More information on organization configuration here.