Bulk Policy Imports Are Fast. But Do You Know What Actually Got Created?

One of the most powerful time-saving features in Commission Tracker’s ICS workflow is the Create Policies utility — the tool that takes the unrecognized policies from a carrier statement and builds them in your database in bulk, rather than requiring you to manually create each one. Done correctly, it’s one of the biggest labor reductions in the entire commission management process. Done without verification, it’s one of the fastest ways to introduce data quality problems at scale.

The difference is whether you use the audit trail that Commission Tracker creates automatically every time Create Policies runs.

Every bulk creation event in Commission Tracker generates a session record. The List of Create Policy Sessions is a historical archive of every time that utility was used — who ran it, when, how many policies were created, and what the data looked like at the time. It’s accessible from the Import menu or from within the Create Policies workflow itself after a session completes.

Each session entry shows the Session ID, the timestamp of when the policies were committed to the database, the user who ran the session, and the count of policies created. Select any session from the list and you can preview exactly which policies were built — the client names, policy numbers, and mapped data — so you can verify that what came out of the session matches what you expected going in.

This is where the audit value pays off most clearly. When a bulk creation session maps policy types, carriers, or commission tables from the carrier file, it’s working from the ICS mapping configuration you’ve set up. If that mapping is even slightly off — if a policy type is being assigned incorrectly or a carrier table isn’t matching the way it should — the session preview will show you the pattern before you’ve compounded it across months of imports. Catching a mapping error after one session means fixing one batch. Missing it means fixing every batch that followed.

The session list is also the accountability layer for multi-user environments. In an office where multiple staff members handle different carrier imports, knowing which user ran which session is the starting point for any data quality investigation. If incorrect policies appeared in your book of business, the session list tells you when they were created, who created them, and what source data drove the mapping decisions. That’s not about assigning blame — it’s about knowing where to look and what to fix so it doesn’t happen again.

One important distinction: the List of Create Policy Sessions is an audit screen, not a management screen. You cannot reverse or undo a session from here. If an entire batch of policies needs to be removed — because the mapping was wrong, or the carrier data was incorrect, or the session ran against the wrong import — that’s handled through the Reverse Import Policy Session tool in the Import menu. The session list tells you what happened. The reverse tool is how you undo it.

Manual policies entered through the Client or Policy screen don’t appear in this list. It only tracks policies created through the automated Create Policies workflow. That’s an important boundary to understand when you’re investigating your data: if a policy isn’t showing up in any session, it was either created manually or created before the ICS workflow was in use.

The agencies that get the most out of the ICS workflow are the ones who treat the session list as a routine part of their import process — not just a tool to reach for when something goes wrong. Reviewing the session immediately after a bulk creation takes a few minutes and confirms the data went in correctly. That few minutes is significantly cheaper than the hours it takes to correct a mapping problem you didn’t catch until the next statement came through.

Fast is only better than slow if the result is right. The Create Policy Sessions log is how you confirm it is.