Skip to main content

​
Dynamic Config

Dynamic configuration is a new Noyo feature where the Noyo system maps 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

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.

​
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 Command Center.