The multi-configuration server is composed of two main parts:
- Base configurationConfiguration: 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 configsSub Configurations.
- Sub configurations 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 ; It must first exist in your base configconfiguration. 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 configuration level, you have a great deal of flexibility over what can be displayed. You can control the following elements:
- Module displayDisplay: You can choose to show/hide a module within a particular configuration. This allows you to configure all objects and control them at a config level, what groups of users seeconfiguration level. For example, you could have an HTML report mapped to a "Summary Report" module in the base configuration. If all sub-configs configurations (except "Manager") have "Summary Report" configured to "skip in cad", only "Managers" see the report when they activate.
- Module properiesProperties: 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 displayDisplay: Which fields are displayed from the "Base configuration" are controlled in individual configsconfigurations. 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 propertiesProperties: 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 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 rulesDownload 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 configuration level.
- HTML / tables Tables / quickselectorsQuickselectors: All can be customised to allow fine control over how data is displayed to your users.
...