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 configs.
- 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).
...
| Info |
|---|
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 config configuration level, you have a great deal of flexibility over what can be displayed. You can control the following elementsExamples of customisation options:
- Module display: You can choose to show/hide a module Modules Mapped: Select which modules are displayed 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", if only the "Manager" configuration has the Skip in CAD checkbox disabled, only "Managers" see the report when they activate.
- Module properiesProperties: You can change 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 .
- Fields Mapped: Map all fields to "Base configuration" are controlled in individual configs. You A "Sales" configuration could have 20 fields in an object displayed for "Field Sales" users and only 5 for "Managers", if only a summary is required.Field propertiesmapped 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", you can change 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 Code (validation): Individual validation rules can be configured for each configuration. This allows you to define what individual control over 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 Managers can have a "receive all updates" rule, while salespeople only have "owner" based updates. This can be configured at a config level.
- HTML / tables Tables / quickselectorsQuickselectors: All can be customised to allow fine control over which data and how data is displayed to your users.
| Child pages (Children Display) |
|---|
...