Snapshot Transactions

Each snapshot request may contain multiple member transactions, which represent smaller sub-operations being carried out at carrier partners. For example, a single snapshot request that enrolls a new hire may result in two member transactions: one to add medical coverage at Carrier A, and a second to add dental and vision coverage at Carrier B.

In the legacy Member Requests integration, this worked the same way. And to get more granular status information than the top-level Member Request status, Noyo advised pulling these transactions and reading their statuses. For even more granular timeline information, the status detail endpoint was made available.

For the Member Snapshot integration, while transactions are still used and exposed via API and Command Center, Noyo does not advise relying on them unless in very specific cases. Instead, use one of the 3 methods detailed in this guide.

For the curious, here are some of the reasons:

• No Tracking Persistence
  Transactions are associated with a single snapshot and do not track changes specified across snapshots. Since multiple snapshots can be sent with a change before that change is fulfilled completely, watching transactions can give an incomplete picture. Relatedly, transactions do not always update their status if fulfillment is confirmed elsewhere, such as while processing a different snapshot or during a routine carrier sync
• Completion with Discrepancies
  Transactions don’t have a structured way to communicate completion when discrepancies may exist with the fulfillment. EOI is a great example, where the transaction complete in its addition of the enrollment, but the volume was not issued as requested. So there is an issue, but the transaction isn’t “failed” per se. This family of cases is where Tracking excels.
• More Sophisticated Splitting
  While the process of splitting snapshots into transactions largely shares the conceptual approach used by Member Requests, more sophisticated splitting exists for Snapshot. Oftentimes Snapshots are split into transactions to satisfy certain technical carrier restraints, detailed temporal considerations, various as_of dates, unsupported and/or manual fields, and more. Member Snapshot Transactions are often unable to properly convey field-level scope in the way that Member Requests offered.
• Custom Policies
  Transactions may remain processing for longer or shorter, depending on your specific contract with Noyo. The transactions API does not return information on specific policy.
• Send Carriers
  The Snapshot integration includes support for Send carriers, which do not currently support Noyo sync and round-trip confirmation. The status detail for successful Send transactions end at carrier_accepted and do not include carrier_processing, carrier_completed, or noyo_verified.
• Future Flexibility
  In an effort to continuously improve the Noyo fulfillment system, it is best to decouple transactions from an externally documented API contract. This allows Noyo the flexibility to change splitting, timing, fulfillment methods, and other mechanics of transactions to optimize fast, accurate fulfillment.