Using custom OMS properties
Custom OMS properties provide a way for custom code to read administrator-managed values from Self Service. This approach helps teams to avoid hard-coded values and change behavior across environments without rebuilding or redeploying customizations.
What are custom OMS properties?
Custom OMS properties are key-value configuration settings that administrators manage outside the development workflow. Customizations read these values at runtime but don’t create or modify them.
- Control behavior that may change after deployment.
- Externalize environment-specific values.
- Enable or disable features without code changes.
When do I use custom OMS properties?
- Single values, such as thresholds or limits.
- Boolean flags that control logic paths.
- Small sets of related values that administrators may update.
For structured, multi-row, or relational configuration data, use CDT tables instead.
How do customizations consume properties?
Customizations read custom OMS properties at runtime by using supported APIs or framework utilities. The values are read-only from custom code.
- Provide safe defaults if a property is missing.
- Handle unexpected values gracefully.
- Avoid assuming that values remain static after deployment.
Testing and promotion considerations
Because administrators manage custom OMS properties independently, test customizations by using representative property values in each environment.
- Do not rely on property values being identical across environments.
- Document required properties and expected value formats for administrators.
Relationship to administration tasks
Administrators create, update, and promote custom OMS properties by using Self Service. Changes to property values may affect runtime behavior immediately, depending on the customization.
For more information, see Custom OMS properties.