Active Directory Query - Wrong info when null provided

[sackett]

I still consider myself fairly new to XSOAR and haven't written a lot of playbooks so maybe I'm doing this wrong, but here's my issue.
When using the Active Directory Query pack's commands (the ad-get-user most recently but I believe ad-disable-account also works this way) it doesn't error when a null value is input. Instead it returns the random objects it finds which can be quite dangerous. 
For instance, I put in ad-get-user with the email parameter filled out to ${incident.labels.Email/From}. I then take the resulting info and use it down the line. As long as that field is filled out 100% of the time it's fine. But the moment some random event happens that I didn't expect and that field isn't there, it doesn't error, it runs the ad-get-user command without the parameter at all. The default limit for pulling objects is 20 so it pulls the first 20 ad objects it can find and moves along. This resulted in 20 random AD objects getting manipulated incorrectly.

In another instance a playbook disabled 20 accounts because the field I was expecting to be there in 100% of all cases was only there 99.9% of the time.

This seems like a bug to me, or am I missing some configuration somewhere of "error on null"? To work around it I've tried doing some sanity checks like counting an array and if the array is higher than 1 then error. But that seems silly when it should just error right? 

Also, side note here. I'm moving my playbooks from XSOAR 6.x to 8.x on-prem and even though the Active Directory Query content packs are the exact same version the 6.x one returns a query as incident.labels.Email/from and the 8.x returns it as incident.labels.Email/From. Note the 'F' switched from lower case to upper. Since that is case sensitive that's what cause my playbook to grab 20 objects instead of just 1 like it has done for years now on 6.x.

[jesseenglish]

There are several places throughout XSOAR where you'll find that you really think an error should be returned, ping for example.  In this case, there's no error because you told it to search for everything.  In cases like this, I'd check that the input value you're using to feed the ad-get-user command is valid or present before searching AD.

[jason_blackburn]

I think I've seen something similar - for running within a playbook context you could apply transformers for is defined or is not empty? 

[jesseenglish]

OP should add a conditional task that checks the value.