Computer in multiple static groups - which takes precedence?

With policies it would probably try to fire all of them off...with profiles usually the most restrictive one on the device wins from what I've seen before. I've actually seen situations where both profiles (with a conflict) will make it and other times, it fail to install them. If both make it, then the most restrictive is supposed to win.

I think you will find it is somewhat random depending on what your trying to deploy and what happens during delivery.
All the APN's will be fired off regardless and the order in which they are received porbably dictates the results somewhat.
I have seen something along the lines of "The profile cannot be applied as a setting has already been specified by another profile" occur for some settings.

With Policies, it's pretty straightforward. If there are no other defined criteria for installation order (Triggers/calls, before and after scripts, Priority, Time Restrictions, etc) they run alphabetically.

I haven't had that circumstance come to the surface when dealing with Configuration profiles (Still... not totally reliant on those yet, I know I know, I've got to get with the program).

Oh, and a profile will stomp all over anything else you can do in a policy. So I guess, if you've got a static group sending out a policy and another sending a conflicting configuration profile, then the configuration profile will win... or uh, well, it SHOULD win.

Do you have a specific example?

So..If I have a configuration profile that is enforced via 'all computers, all users' and upon 'check-in', but I also have a configuration profile with most of the same properties but it acts on a smart computer group (specific computers, specific users and upon checkin). Will the more restrictive configuration win regardless or will they both fail.

Let's say I want to, in the security & privacy area, set the default of immediate for the screen lock, but then a static group wants to set it to 5 minutes.

Will 5 minutes, or immediate be set? Or will they both fail and neither configuration will be set?

@erich.proudfit why not just exclude that smart group from the overall configuration profile? Then you can target that smart group with the 2nd configuration profile and not worry about any conflicts.

As @Chris_Hafner and others above mentioned, what SHOULD win is the more restrictive setting, meaning "Immediate" in your example, but, I'll be honest with you. Your best bet is to ensure no overlapping and conflicting profiles are being pushed to the same Macs, just because the behavior isn't entirely predictable. Use exclusions or other scoping mechanisms, Smart Groups, etc to ensure that only one profile with the same payloads are being deployed to your clients.
That's going to give you the most reliable experience.

@mm2270 Thank you. Yes..that is the best way to 'ensure' the configuration I want.

It was more of a what-if scenario.