Without inside knowledge of both apps (which I lack) I can only speculate.
Apps that modify default behaviors generally "hook" the system. As an example, lets say you have software that blocks urls to adult web sites. There's a jump table the system uses to store the location of the DNS resolving program. When something wants to resolve a url, they call the routine at that location.
Your software would copy the address at that location, and then replace it with YOUR address. So when someone looks up a domain, they ask you instead of the DNS software. Your software can look at the request and decide whether to return an error code, or to forward it to the DNS software. This process goes by a few names, but "hooking" is common. It's also possible your software may return a bogus or different URL instead of returning an error or passing the call to the DNS routine. That would be an "override" of sorts, and your participation would be invisible to the caller.
It's possible for more than one piece of software to hook a call. Then it starts coming down to a matter of who hooked first. If my program hooks before yours, and someone makes a DNS request, you'll get called, then you will pass it to me, and I will pass it to the DNS program. (assuming neither of us rejects it)
That would be post-hooking. Hooking can also be done interim. For example, your software might have a url whitelisted, and when someone looks up that domain, your software disables the firewall, calls the DNS, and then re-enables the firewall before returning the DNS's results to the original caller. That'd be an interim hook. Because sometimes you want to take action after the actual call is made. (maybe for logging, for example)
In the case of a service, everyone involved in hooking the service would have to pass it through to allow it to be serviced normally. There'd be no way for one service to override the others. But lets say its more of an approval. Lets say there's a service to simply tell you if something is allowed (like a URL) or not. If you are the last one to hook it, you get first crack at it and can approve it instead of passing it on to the previously assigned routine. (or routines, if it had already been hooked) You hooked it last, you have first crack at it, and its possible that no one else gets a chance to deny it.
And sometimes a service is outright completely replaced. In that case, the hooker may store the previous value before replacing it, but it won't ever call it. It's now in charge of providing the service. Maybe you've customized the GUI sound effects, and there's NO reason for you to be calling the defaults since you replace them. You might keep the original on hand though in case you offer the ability to disable yourself without a reboot, so you can put back the original value.
So generally speaking, either everyone has to allow it, or it's last-hook-wins. (or at least has first crack at it) It really depends on the service.
This makes it difficult to predict how different programs will behave when ran together, and this is why pretty much none of them will support their software if you're also running something else that may be interfering/interacting.
Let me give an example of undefined behavior: lets say you have two pieces of software, one that turns off the firewall for certain URLs, and one that does additional lookups (checks to see if a server is running HTTPS if you make an HTTP request, to let you know you have the option) If the firewall opener hooks last, the order of operations will be (firewall off)(https check)(http check)(firewall on) But if the https checker hooks last, the order is changed to (firewall off)(https check)(firewall on)(firewall off)(http check)(firewall on). If the firewall takes awhile to recover from being turned on, the http check that follows right after getting the firewall turned on and back off may fail for some reason of timing. Note this sort of thing may also lead to performance problems. (if it takes 1 second to toggle the firewall, this request takes either 2 OR 4 seconds depending on hook order) Unpredictable behaviors like this is why vendors don't like dealing with systems running other unknown software.
TL;DR: there's no way of knowing without testing or finding documentation on it
