Trouble understanding how Profiles and Smart Groups are supposed to work together

Question

Fist off, I think CiviCRM is awesome! As an erstwhile systems software programmer from the nineties who saw the birth of the World Wide Web while working for major corporations and governments it is truly heartwarming to see how far the OpenSource movement has come!

I'm working to set up CiviCRM for a new food Co-op, and I admit that despite reading the User Guide pretty thoroughly I'm struggling to understand how Profiles and Smart Groups are supposed to work together. I've set up profiles for Donors, Volunteers, Newsletter recipients, Members, and Founders (members who also sign up for contributing founders' credit to help open the co-op.)

I'm probably missing something glaringly obvious (note I said systems software programmer, user interfaces have a tendency to escape my understanding,) but I guess I'll just describe what I'm trying to do and how, and hopefully some kind soul will speak up and say "Whoa, whoa you're way overthinking this, this is how it's done..."

I am trying to set up smart groups so that our community outreach people can email the various groups as appropriate. On the surface it sounds like I need a Founders SG, a Members SG which is a parent of Founders, a Volunteers SG, and a Newsletter SG which is a parent of Volunteers and Members. That way, an email to the Newsletter group will go to everyone, but an email to the Volunteers SG will only go to volunteers.

However, I've already learnt the hard way that SGs, unless they are defined via clear search criteria, aren't as "authoritative" as they could be. Twice now I've discovered that all my contacts have somehow ended up being members of a SG. This may have something to do with the parental inheritance thing, however if I define a SG with a clear rule, it does seem to stick in a meaningful way. Of course, if I do that, then setting the "add to smart group" field of, say, the Volunteer profile to "Volunteers" will only remain valid until the Volunteer smart group (which selects based on a relinfo::Volunteer = Yes criteria) updates itself, which is to say, not very long.

Also, I can't seem to figure out how to associate profiles with automatically set fields. It feels awkward to create a volunteer signup profile with a "check this box to signup to volunteer" field as opposed to just having a hidden field with the value automatically set.

So my current thinking is, that I need also to also create SG's for Volunteer Signup, Founders Signup, Newsletter Signup, and have the associated profiles add new contacts to those groups. Then I can periodically run a cron job to set the appropriate relinfo:: fields for contacts in the signup groups (thence they will be members of the non-signup groups) and remove them from the signup groups. This already is starting to seem a bit complex, thus my request for input :)

However, because the update job will likely only run once a day, there's a period where someone can have signed up as a volunteer, for instance, and yet not be in the Volunteer SG. Given the slight oddness around group parentage stuff, I'm concerned just making Volunteer the parent of Volunteer Signup will muddy the waters, and that it would be clearer to create Volunteer Email SG, parent of both Volunteers SG and Volunteer Signup SG, etc. for the Newsletter and Founders' Credit SG's Members seemingly isn't as much of a concern because if people submit that profile they are automatically marked as Members, and when people sign up as Founders they also are completing the Members Profile and will thus satisfy that criterion. However, Founders it is the resulting Founders' Credit contribution that they would be the basis for adding them to the Founders SG.

So, is this the way it's done, or am I missing something? From my perspective this would be many times easier if I could just silently set fields as part of profiles.

Thanks for your attention :)

Answer 1

Pete has identified the core issue here and given your comment response, I'll try to expand.

You want to add people to a group as a result of them completing a profile. There are two approaches with important differences. You can use either one, but you're trying to use both which leads to confusion!

Method 1) Use a normal group (not smart), and use the profile setting to add contacts to that group when the profile is submitted.

Method 2) Use a smart group for eg Volunteer=Yes, don't use the profile setting.

Which method you want depends on what meaning you give to the group. What should happen if you later change a contact's info so that Volunteer=No ?

• If you want them to stay in the group ("contacts who completed this profile") use a normal group (method 1)

• if you want them to be removed from the group ("contacts with Volunteer=Yes") use a smart group (method 2)

While it is possible to manually add people to a smart group that's usually a bad idea (shooting yourself in the foot is possible but usually bad!). Keep smart groups defined only by criteria. Use normal static groups when you want to manually add/remove. [As often, there can be exceptions to the rule when you know why you're breaking the rules!]

Answer 2

Hard to know quite how to unpick what you have posted but the bit that stopped my eyeballs in mid-skim was this

setting the "add to smart group" field of, say, the Volunteer profile to "Volunteers"

Not sure if you have the concept but a Smart Group IS the results of the Search used to find the people who should be in it, ie it is a set of criteria, not a set of contacts.

By adding contacts to a Smart Group via a Profile means they ARE in the Group, but they are not SMART - ie you are not using the 'criteria' to determine if they are in the Group or not, you are force adding them (which is allowed for Smart Groups but you have to understand the distinction)

Not sure if that helps