Multi-configuration structure / features

Owned by Dorian Port
Last updated: Jun 19, 2015

The multi-configuration server is composed of two main parts:

  • Base Configuration:  This is the master configuration, which contains all modules / fields / settings used across all other configurations.
  • Sub Configurations (multiple configurations):  These allow you to customise a base configuration to suit the individual needs of you users (for example, Salespeople seeing a different interface/data to Managers).

Modules / fields cannot be mapped directly from the data source to a sub-configuration, it must first exist in your base configuration.  If viewing Base Configuration, selecting Map Modules will show all modules from the data source that can be mapped.  If viewing a sub configuration, selecting Map Modules will show all modules from Base Configuration not already mapped in the current sub configuration.

This ensures that regardless of the individual configurations, all modules and fields mapped from the data source are structured identically in all Swift MEAP™ configurations.  All modules and fields will have the same data structure names/numbers, regardless of how many configurations are created. 

Sub Configuration features

At an individual configuration level, you have a great deal of flexibility over what can be displayed.  Examples of customisation options:

  • Modules Mapped:  Select which modules are displayed within a particular configuration.  For example, you could have an HTML report mapped to a "Summary Report" module, if only the "Manager" configuration has the Skip in CAD checkbox disabled, only "Managers" see the report when they activate.
  • Module Properties:  Change the sort order, read-only properties, create properties, context settings, menu settings, labels etc at an individual configuration level. 
  • Fields Mapped:  Map all fields to "Base configuration".  A "Sales" configuration could have 20 fields mapped in Activities, a "Managers" configuration may only need 10, if summary information is required for Managers.
  • Field Properties:  In addition to which fields are displayed in a "configuration", the individual order, labels, read/write/hidden properties of any field from the current module can be changed.  "Managers" can therefore have access to view/edit fields that your "Sales" users do not.
  • JavaScript Code (validation):  Individual validation rules can be configured for each configuration.  This allows individual control over processing/rules performed whenever a user edits, creates, saves records, depending on their configuration.  An example could be an organisation where groups are divided into "regions", one region can have a completely different set of validation rules to another.
  • Getupdates / Download Rules:  Managers can have a "receive all updates" rule, while salespeople only have "owner" based updates. 
  • HTML / Tables / Quickselectors:  All can be customised to control which data and how data is displayed to users.