Selection Field Administration Featured Hot

by Tom Clement on November 07, 2015

Selection field values are currently specified in Composer and can be enabled or disabled in Application Administrator.  This idea proposes that we add a variant to the selection field that changes selection values from being design constructs to administrative constructs. For people who need to frequently change, add or delete selection values, this would permit that work to be done administratively without redeployment of the process app.  The enhancement would include the ability to convert from the design values to administrative values to address issues with existing process apps.

  • Many SBM customers use selection fields and corresponding dependencies to manage lists of options in their applications. Changing these lists requires the SBM administrator to open the corresponding process app in Composer and make the changes there, then redeploy.  If this is done infreqently and the lists are relatively small, this is not too much of a burden, bot for many customers, their use case involves frequent changes and large selection lists.  This idea proposes that we add a flag to the selection field definition in Composer that causes the selection values to be editable in Application Administrator and not appear in Composer.  This way, selection values and dependencies could be changed without redeployment.

    To address the situation of SBM customers who already have large and changing selection value sets, we would permit this change to be made on the fly, so that existing selection values and dependencies could be removed from the process app definition and into the administrative realm.  This could dramatically reduce deployment time for some process apps and reduce the need for frequent deployments by making the changes administrative in nature.

    These administratively defined selection values would not be part of the blueprint when exported from the Application Engine, and would not 'round trip' to Composer.  However, like other administratively defined values they would be promoted between environments.  (From a technical perspective, this simply means the definition of the selection values and dependency definitions would be moved from 'definition.xml' in the blueprint to 'instance.xml' in the snapshot.)

    We would need to look into the use of selection values in Composer, for example, in rules and transition actions.  Since these values would no longer exist at design time, perhaps we would want to support a hybrid field type where some values could be administrative and others still exist in design.  (This would complicate the design, however, so we'd need to understand the demand surrounding it.)

  • Please login to view any attachments.

  • This idea has not received many votes in 24 months since its submission. It has been closed (declined) due to insufficient support.
    David J. Easter Commented by David J. Easter June 04, 2018
    #1 Reviewer  -  

    This idea has not received many votes in 24 months since its submission. It has been closed (declined) due to insufficient support.