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 :)