Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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.  If a module / field does not exist in the base configuration, it will be unavailable in Sub 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).


You cannot map a module/field at a sub-configuration level; It must first exist in your base configuration.  For example, if viewing Base Configuration, selecting Map Modules will show all fields from the data source not currently mapped.  If viewing a sub configuration, selecting Map Modules will show all fields from Base Configuration not already mapped in the current sub configuration.

This ensures that, regardless of the individual configurations, all fields mapped from the data source are structured identically in all Swift MEAP™ configurations.  Everything is added to a single source (Base Configuration) and once mapped, it is then enabled at a sub-configuration level.

Sub Configuration features

At an individual configuration level, you have a great deal of flexibility over what can be displayed.  You can control the following elements:

  • Module Display:  You can choose to show/hide a module within a particular configuration.  This allows you to configure all objects and control them at a configuration level.  For example, you could have an HTML report mapped to a "Summary Report" module in the base configuration.  If all sub-configurations (except "Manager") have "Summary Report" configured to "skip in cad", only "Managers" see the report when they activate.
  • Module Properties:  You can change the sort order, read-only properties, create properties, context settings, menu settings, labels etc at an individual configuration level, allowing you to present data differently and control which groups of users can change/edit/create/view records.
  • Field Display:  Which fields are displayed from the "Base configuration" are controlled in individual configurations.  You could have 20 fields in an object displayed for "Field Sales" users and only 5 for "Managers", if only a summary is required for Managers.
  • Field Properties:  In addition to which fields are displayed in a "configuration", you can change the individual order, labels, read/write/hidden properties of any field from the current module.  "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 you to define what processing/rules are 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:  You may want managers to have a "receive all updates" rule, while salespeople only have "owner" based updates.  This can be configured at a configuration level.
  • HTML / Tables / Quickselectors:  All can be customised to allow fine control over how data is displayed to your users.


Filter by label

There are no items with the selected labels at this time.

  • No labels