View Source

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 all other configs.
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, if it does not exist in your base config. 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 config 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 at a config level, what groups of users see. For example, you could have an HTML report mapped to a "Summary Report" module in the base configuration. If all sub-configs (except "Manager") have "Summary Report" configured to "skip in cad", only "Managers" see the report when they activate.
Module properies: 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 configs. You could have 20 fields in an object displayed for "Field Sales" users and only 5 for "Managers", if only a summary is required.
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 config level.
HTML / tables / quickselectors: All can be customised to allow fine control over how data is displayed to your users.

Sub configuration features

Related articles