Well... durr (on my part). I thought I had the trigger as ANY arrives. I wasn't even looking at the trigger when I posted this and your answer is obvious because of my oversight. Redundancy aside, is the action formatted correctly if my trigger is "ANY arrive home"?
I hate feeling stupid. 
I updated it. Now does the action make more sense as is?
Quick question, is there any condition where one of you "arriving" would not result in them being "present". I ask this because to me the check to see if one of you is present is completely redundant if the rule is being run. To me it seems that the only if checks should be mode.
Now if you want individual and personalized notifications then you can check for the individual person, but that will get complicated pretty quick.
I think you are both right. :\
You did, basically. A "Sensor 1, Sensor 2 any arrives" trigger should be identical to "Sensor 1 arrives OR Sensor 2 arrives." In fact, I might prefer the second: there was a bug (?) a while back where the first trigger would still match--thereby running your actions--when any sensor changed and one happened to still be present (e.g., had last arrived), or at least this was true for some attributes.
Looks like the conditionals are the same as the original? Possible bug aside, these should still only be running when any of the sensors are present, so the "AJ Present OR Heidi present OR Jonathan present" portion of the condition can be eliminated--if you want to save clicking. If you don't, it's harmless to leave in. You know it's true already or the actions wouldn't be running in the first place, but it doesn't hurt to check. (And again, given the "single 'any' trigger' issue, you actually might want to leave it if you keep that trigger...)
The "arrived" trigger matches the "presence" attribute becoming "present." (It's a bit confusing that the name doesn't match either the attribute or its value, but I suppose it's an intuitive description of what's happening.) So, a trigger of Sensor 1 arrives OR Sensor 2 arrives will always result in a condition of Sensor 1 present OR sensor 2 present being true in the actions, if that's the question being raised here.
Yeah. after I read it when I was editing it, I thought a lot of this. I modified it to not include the people arriving again. I'm coming from SmartThings and I'm not used to this kind of flexibility (or needing WebCore to get close to it). Here's what I changed it to.
That seems good to me. Is it working as intended? You can check by manually manipulating the presence sensors. Also you may want to control the mode control not manually like you are doing here, but rather via the mode manager.
I also would take a look at this app which will make your life easier and/or improve presence detection:
For your use case you could combine the three presence sensors into an "Overall" presence and then use that abstracted "Overall" presence in rules.
How can i manipulate the presence sensors?
That looks good to me, too! I'll repeat the warning others have said about not relying on presence to automate things like locks or garage doors, but (if your sensors work reliably) I trust your own judgement there. 
(EDIT: On that note, it looks like you're unlocking a door and opening the garage when you leave? EDIT 2: D'oh, nevermind, not really, just depends on the mode...)
I don't think so, this rule only handles when someone arrives, just depending on the current mode it does different things.
I've never had Life 360 false positive on me and my phone would blow up if the garage opened when i want there. Add to the fact that it is a condo complex where i know all my neighbors, and I'm ok with the risk! 
Thanks everyone for helping me think straight!
No this is on arrival.
Yep, I got confused! 
(Moments after twice stating myself what the trigger was? Yes.)
If i do that, do i have to put them all back in sync after?
Does not really matter in my experience, they will be fixed next time the geofence is triggered (in or out), but yes for best practice return them to the state they should be in. Remember these are just Hubitat abstractions of the L360 data, not the L360 data itself.
There is another subtlety that you should be aware of. Triggers are events, not conditions, such that no two triggers will happen simultaneously.
So, after one trigger event happens, while a process thread is running the rule on that first trigger, another of the trigger events could occur, such that you now have multiple process threads running the rule concurrently. You have no control over the scheduling, no control over which thread will finish first, etc.
Just bear this in mind.
If I am understanding this correctly, then he may have this rule running up to three times when he just wants it to run once correct?
If this is the case, you can get around this with the community app I listed above to combine the presence sensors.
Yes.
I probably, I haven’t studied that app. The point I was trying to make is that triggers are independent events that can trigger the rule, independently.
Good to know, thanks for the heads up.
I guess I can use the app that @cjkeenan suggested, but the mode change is the first action; that should alleviate multiple running of the first part.. the likelihood that 2 people enter the geofence at the exact same time is very low and, worst case, it just runs twice?
@cjkeenan do you know enough about that app to give me advice? Like... if I set this up in this instance, it looks like I should be using the boolean OR option?
Download the Hubitat app
