Benefit Groups - Dynamic versus Saved

We've been discussing and testing internally and we also have an incident opened with Infor about this but still yet to understand any positive benefit to having your benefit groups set to Dynamic instead of saved.

Does anyone else have their groups set to Dynamic? Have you seen any added benefit to having this setting?

With the benefit group set to Dynamic you still have to do everything else to see memberships as if the benefit group was set to Saved. There is no reporting or screen data within GHR reading the membership dynamically and both IPA and IPD follow the same only seeing the data that is in the business class BenefitGroupMember in bn/Business Classes. So even with Dynamic set, you still need to refresh the benefit group membership as you do with the Saved setting.

I'm waiting for Infor to respond to tell me exactly what jobs or where within the system utilize the dynamic setting reading real-time membership data. i'm assuming the dynamic configuration is only good for any jobs that run within Async but waiting to hear back.

We build our benefit files that get sent out to our benefit companies via IPA so it's only as up-to-date as the last manual refresh of the benefit group. Everything with our testing still points me back in the direction that having your benefit groups to Saved is likely faster than dynamic because i get a feeling the system looks at two places for every decision when set to Dynamic - it will check the saved database information as well as go out and make a real time decision.

i just wanted to know if anyone else had tried to understand the differences between the two and also curious what setting everyone has this set to. Do you refresh benefit group memberships nightly or how often? What's your average run time for refreshing?

Find more posts tagged with

Accepted answers

All comments

nhoppe

when we went live 4 years ago, we set our benefit groups to Dynamic, but it never refreshed anything, even though that is what Infor said it did. (based on a support ticket). I couldn't find any benefit, no pun intended, to the Dynamic setting. We still have it set that way, but run the refresh membership process every night on a scheduled basis. We are a large school district with employees who come and go and/or change FTE and work status on a regular basis.

unknown

Hi Nancy, this is unrelated to this thread (sorry), but we are currently struggling with eligibility record dates and very frequent work status/FTE changes with our staff too.

How are you handling this with your custom group criteria? We currently have eligibility entry rules based on start date but that is causing issues when they change status after their hire-start date period. Are you using a custom date field for benefits eligibility, or something else?

Jennifer Stroud

We use a custom date field for benefit eligibility date to accomodate changes in status post new-hire period.

unknown

Thank you! We are concerned about having to manually maintain another custom date field and human input error. Do you have any special way to maintain-monitor that date or just relying on the user entering that date field to be accurate?

unknown

Dynamic is actually the older original implementation while saved is the newer optimized behavior that can use "cached" values instead of constantly recomputing membership information. As such it would be ideal if you *didn't* see any benefit to using the dynamic because that would mean you can see all the benefits you wanted with the faster optimized setting. However, I believe if you use the Saved setting and you *don't* refresh membership, you can end up with out-of-date outputs from processes that depend on benefit membership information whereas Dynamic membership will always produce correct current output regardless of when membership data was last refreshed. There are, however, some views of membership information that *only* display the saved membership information, and those views, of course, do not benefit from the Dynamic setting.

It's been quite a while since I was deeply involved in this, so I could be off, but I believe the trick is refreshing precisely the right data at precisely the right time when using the Saved setting. Refreshing membership information may be sufficiently low-impact that there's no reason not to refresh all membership information without too much concern over exactly what needs to be refreshed (what will be actually used) but if you are running a process where you can't easily identify what membership information needs to be refreshed in order for it to process correctly, maybe you would get better performance out of using Dynamic membership rather than Saved because the Dynamic lookups might be looking up a much smaller subset of membership information than the full set of membership information you might otherwise have to refresh without knowing exactly what memberships are involved.

One example where you might be able to run a process without refreshing membership first is mass enrollment. Mass enrollment takes a Benefit Group parameter, and if the membership is not updated before running this process, you might get enrollments based on outdated group memberships.

reaganr

Hi Noe,

Thanks for posting this thread. This is an interesting topic that I haven't researched. We have had our benefit groups set to dynamic since our go live in 2021 and haven't had issues. We do have to manually refresh groups if we are looking into an issue for a particular employee. I don't believe we are refreshing the benefit groups nightly. We built our benefit vendor files with IPA as well and haven't had any issues. The IPA do take a really long time to run though.

I'll be interested in Infor's response to you. Would you post that information to this thread when you hear back from them?

Thanks,

Rhonda

Copyright © 2025 Infor. All rights reserved.