Hi Mateusz,
Welcome to the community!
In general what the rule is targeted at defines where the rule is run (and where events are located). If you’re targeting a group you may find that the rule is run on a management server rather than the members of the group (the management server looks after the group).
Typically if you are logging an event in a PowerShell script (eg using the logscriptevent method on the API) you’ll want to look in the Operations Manager event log on the machine that is running the workflow:
For debugging PowerShell I absolutely love transcript logging (and rave about it like a lunatic).
In my experience, there’s no real issue pulling in modules (as long as they are in an accessible scope). Snapins are old and weird but behave quite similarly to modules so I can’t foresee any immediate issues with them, but I’ve never tried.
The other issue you may have is the agent account. Generally (but not always) this defaults to the local system account. If that doesn’t have access to what you are trying to pull in you may need to look into run-as accounts to use to connect to your source. A quick and dirty workaround I’ve used in the past is to use a scheduled task to dump the required info to a CSV/XML file which can then be picked up by your rule.
Longer-term it might be worth looking at authoring, which will allow you to do a lot more with a bit of work. Channel 9 (R.I.P) used to have a great course on management pack authoring that went into some of this in more detail. Through The Wayback Machine it might be possible to get at the lessons still. Unfortunately, I don’t know of anywhere else currently that the content might be hosted.
Failing that MP University and SCOMathon both have some pretty decent sessions on authoring if you look through the past sessions. Kevin Holman has also partnered with MP University to produce a whole bunch of content that can be found on his blog.