Skip to main content

​
Dynamic Configuration

Dynamic config is a new Noyo feature where Noyo takes on the mapping logic for most account structure values and surfaces any remaining unknown logic to you for your input. While this may present an extra step when connecting some groups to new carriers, it allows the initial integration to member snapshot to support all carriers and removes the need for carrier-specific fields to be passed in snapshots.
Dynamic config is recommended for all new Noyo integrations and eliminates the need for carrier-specific values to be coded into member snapshots for each new carrier connection.

​
What plan data should I send?

Your snapshots should include a consistent internal ID for each plan in your system (as the custom_plan_id) and your name for each plan (as the plan_name). The custom plan ID being static allows us to reliably map your plans, even if the plan name goes through minor changes.

​
What member data should I send?

Carriers have different ways of dividing up members into different subgroupings, and these methods can vary by carrier as well as between different groups at the same carrier. In order for Noyo to map your groups correctly, we need to be able to determine which members fall into which category. Noyo recommends that you capture as much information about employees, dependents, and their coverage options as possible in every snapshot to ensure compatibility with as many carriers as possible. Noyo will create rules based off of information passed in the coverage block, as well as information included in the employee.classifications object.

​
Classifications

The classifications object is appropriate for subgroup information that applies to the employee or their entire family. The classifications block does not have a defined schema as it is designed to accept any relevant data. Recommended information for the classifications object includes:
  • Division, branch, team, or department info
  • Company location/office name
  • Leveling info (management, supervision, director, executive, key person, etc.)
  • Subsidiary number or name

​
Classifications Changing Over Time

By default, Noyo’s system will assume that a classification applies to the employee family for the entire span of all coverages in a member snapshot. If this is not the case, classifications can be given effective dates. Imagine a scenario where there is a subgroup for executives, and a subgroup for all other members. If an employee who was not an executive is promoted to become an executive, we may not want their coverages to be impacted back to their original start date. The safest way to handle this is to add an as_of date to any data that has changed since the beginning of the earliest coverage in the member snapshot (or earlier). This classification block represents that the employee is a “Head Attorney” and in the “Attorneys” job category for all of the coverage blocks in this member snapshot. It does not include any adjustments to time periods. 
"classifications": {
  "job_title": "Head Attorney",
  "is_executive": false,
  "job_category": "Attorneys",
  "custom_field_19": [2025, 2026, 2027]
}
However, this classification block shows that the employee should be mapped onto the executive sub group starting 2025-01-01. 
"classifications": {
  "job_title": [
    {
      "value": "Head Attorney",
      "effective_date": "2024-01-01",
    }, 
    {
      "value": "Chief Legal Officer",
      "effective_date": "2025-01-01"
    }
  ],
  "is_executive": [
    {
      "value": false,
      "effective_date": "2024-01-01",
    }, 
    {
      "value": true,
      "effective_date": "2025-01-01"
    },
  ],
  "job_category": "Attorneys",
  "custom_field_19": [2025, 2026, 2027]
}
The effective date is inclusive, and means that the data in the “value” key is correct from that day until the next value’s effective date, if any. You should send a classification value back as far as the earliest coverage, so that we can properly map the employee. It is safe to put an arbitrarily early date to represent the earliest data that Noyo needs to have. If you would prefer to send only the latest date for your classifications, and would like to carry forward older dates rather than sending the full timeline in each member snapshot, reach out to Noyo for guidance.

​
Carrier Config Values

For data that might be different for different enrolled members, or that might be different per coverage, or change over time you can use the carrier_config attribute within a coverage block. This will accept any schema. An example of where to use a carrier_config value is when a single plan has “high” or “low” options. If an option can be elected separately per person, even if the entire family is on the same plan, then “high” or “low” should be defined in the config. The carrier_config values are assumed to apply starting at the “start_date” or the “latest_change_effective” date of the coverage, whichever is later. 
"carrier_config": {
  "coverage_selection": "high"
}

​
Plan Year Sensitive Data

Most mappings are plan year sensitive, and may change somewhat between plan years. For example, imagine that attorneys are mapped to sub group 1 in 2025 and sub group 2 in 2026, and the plan year starts on January 1st. If a member snapshot comes in for an attorney with coverage from 1/1/2025 that continues indefinitely (until 12/31/9999), Noyo can split that into two coverages: one that maps the person to sub group 1 (for all of 2025) and one for sub group 2 (for 2026 onwards). However, in order to avoid prematurely sending the carrier information about a future plan year, Noyo will only apply rules about a current or previous plan year, unless the snapshot contains an explicit reference to future data. In this scenario, we would split the coverage if:
  1. It is currently the 2026 plan year or later.
  2. It is earlier than the 2026 plan year, but open enrollment is upcoming, so snapshots are interpreted as including information about 2026
  3. It is earlier than the 2026 plan year, but the start date or latest_change_effective date for one or more coverage in the snapshot is for a date in the future plan year
  4. It is earlier than the 2026 plan year, but a classification has an effective date in a future plan year.

​
Pre-release Caveats

  • When using sandbox/test groups, explicit configuration may be required until rules are written. Your implementation team will provide guidance on how to structure snapshots for testing.

​
What’s not supported with dynamic configuration

The following scenarios are not currently supported when using dynamic configuration to complete mapping:

​
Family/Employee Tiers

Family/Employee Tiering involves separate plans or configurations for an EE alone versus an EE and their family. A common example of this is that an EE enrolling alone gets put on the “EE Only” plan at the carrier, but if they need to add their family to coverage, all members of the family (including the EE) are put on the “EE + Spouse” plan. If your system only has one plan for both the EE and EE+FAM enrollments and you’d need us to infer the correct tier based on who’s enrolled, we will be unable to map this coverage. However, if you’re able to send us a configuration value for each enrollee with the explicit tier information, we would be able to assign people to the correct tier within the plan.

​
Mapping based on another coverage’s plan selection

This scenario is most common with Principal Financial products. Instead of having two dental plans, “Dental High” and “Dental Low,” there will instead be one dental plan with two configuration values like “Members electing Dental High” and “Members electing Dental Low.” These configuration values would then be needed for Life insurance elections to determine some aspect of that coverage. We are not currently able to use the configuration value from the Dental coverage to send a value for the Life coverage.

​
Adding or bundling coverage

If your system has two coverages bundled into one, such as Life/AD&D, and set up as one plan in your system, but the carrier has them as two distinct LOCs and plans, Noyo is not able to accept a single Life or AD&D enrollment and add the other coverage to it. We need to receive each enrollment in its own coverage block in the member snapshot.

​
Ignoring or removing coverage

We are not able to ignore coverage blocks in member snapshots or map them onto nothing. Each coverage must have a matching coverage it’s mapped to. Some common examples of questions we get around ignoring/removing coverage are:
  • The carrier bundles medical and dental into one plan but we have two in our system, can you just ignore the dental enrollment?
  • Our system is trying to enroll a child in a plan that doesn’t allow children, can you just map their enrollment to nothing so it gets ignored?
  • Can we send you enrollments for coverages not supported by Noyo and you just ignore them?
In all cases, the answer is that we aren’t able to support those scenarios today. All coverages in a snapshot must map to a valid plan or configuration.

​
Explicit Config

In previous versions of Noyo, member snapshots required explicit carrier configuration to be defined on every incoming snapshot as detailed in Mapping plans and account structures. This is a multi-step process that involves:
  1. Pulling down the carrier’s view of the group
  2. Mapping your system’s stored information to the carrier’s group structure (benefit classes, subgroups, bill groups, divisions, locations, etc.) along with plans
  3. Sending the correct values on every snapshot
Using explicit carrier configurations will avoid any mapping tasks when connecting a group, but the structures and required fields differ by carrier and often require carrier-by-carrier engineering work. Sample snapshot carrier configuration blocks: 
{
    "benefit_class_identifier": "0001",
    "benefit_subclass_identifier": "0001-01",
    "bill_group_identifier": "0000",
    "bill_subgroup_identifier": "0000",
    "work_location_text": "ABCD1234"
}
For a fully enumerated list of per-carrier fields, see the Carriers page in the Noyo web application.