How to include disconnectors in a set?

Question

This is an interesting scenario I haven't got a good answer for at the moment and wondered if anyone else had any good ideas?
As part of meeting a user deprovisioning requirement, when a set of conditions are met, we need to take action and delete the user in the Portal. Pretty simple so far, create a set with dynamic membership and have a MPR fire on transition-in to the set.
The problem though is that one of the criteria for the set needs to be "the user has been deleted from the authoritative system", i.e. they've been disconnected from their source system (not the Portal).
There's no way in the set criteria builder to ask that sort of question of the sync engine "do you have a connector for XX MA?" that I know of.
There doesn't seem to be a way to set an attribute in the MV on the user when the user is disconnected to use as a marker either. I did think about trying to hijack the ShouldDeleteFromMV() method on the Metaverse extension but I doubt very much it'll
be able to modify the mventry and if it does, it means I have to implement code to determine the object deletion rule.
I could use a reflector MA, something that queries the MV database table directly for all users and then use a rules extension to set the MV attribute that says if they have the connector or not, but it'll be slow due to needing to do full-syncs (80k+
users) and therefore not something we can include in the normal fast-paced cycles, so would have to run say once a day on its own schedule.
I don't suppose anyone else has a nice way to make this kinda of is-connected determination in the portal, ideally with a set?

Answer 1

Thanks Glenn and Brian.
The ShouldDeleteFromMV method can't be used as whilst it would be able to detect the disconnection, this is only one part of the criteria for deletion, the other criteria wouldn't be met at this point (the disconnection happens
first, then other attributes change state over time to get to the point where we can say all criteria are met), so I'd never be able to return true from that method.
Attribute recall can't be used on the existing authoritative system MA's as we need attributes to remain in the Metaverse until the identity is fully deprovisioned. I could create a second MA that only flowed this attribute, though the idea of another big
connector space doesn't exactly fit well with the attempts we're making in terms of performance gains, though it may be necessary.
Oh, just to add, I'm using a hybrid model, so classical Metaverse extension provisioning with portal workflows, mainly because this is an ILM to FIM migration project.