NERM Attribute Configuration

Hello folks,

I came across a configuration pattern in a baseline workflow and I’m trying to better understand its purpose.

Specifically, the workflow includes:

  • Setting sysconfig_enabled_features by pulling it from the System Configuration Profile
  • Setting System Configuration Profile to a static value: “NE Server”

From what I see, these attributes are added to the profile during creation. But I’m curious — what’s the actual purpose of this setup?

  • Is this acting like a central configuration repository, where shared rules/features are defined and inherited by profiles?
  • Or do they serve a different purpose, like dynamic configuration management, profile categorization?
  • How are these typically used in a real NERM setup?

Appreciate any insights or examples from others who have used similar patterns.

This setup uses the System Configuration Profile as a centralized config repository. The sysconfig_enabled_features are flags that control which features are active in workflows. Assigning a static value like “NE Server” links workflows to a known baseline config. This allows dynamic behavior based on environment or profile type. It’s commonly used in NERM setups for consistent, scalable configuration management.

1 Like

That system configuration profile was used as a configuration repo for various settings and attributes to reduce the need to replicating across workflows and templates. Some of this has been replaced by OOTB variables now, specifically around the url and api tokens. The options around the features/approvals/etc were there to allow quicker adjustments to processes prior to a final implementation where the business processes would be fixed. So in a real environment you probably aren’t going to have a profile like this and instead build your workflows to handle the flows specific to your requirements.

In the end, real implementation workflows will be much simpiler without all the variations that are included to support the variation in configuration too, which is why the baseline workflows are more complex.