Process for Guarding Against Pre-PRD Automated Communication

Hi @GDFMNICHOLS,

Depending on how your environments are set up it may be easier to deny traffic leaving the server in general rather than amending FSM. That way FSM still runs identically but as soon as traffic tries to leave it will have no-where to go. That way you can see what FSM is attempting to send and where from the exception logs on the server where the send gets denied.

How you do this really would depend on what your setup is though i.e. if the database and app are on the same server you could just completely shut down all traffic off of that server and run the app client locally. More likely the DB and app server will be separate but, if the notification all send outside of a local intranet then you could deny wider web access to the server etc.

This then has the benefit that you are not risking missing one particular record or piece of data that needs to be sanatised before testing.

Kind regards,

Lee Pinchbeck

Thank you for the response. I can definitely see the merit in this response, but I don’t think is the best solution in our case because we do need communications to go out for the purposes of testing email and text communications as well as integrations.

I think we are going to go down the route of writing a query to automate a lot of this through app params and routing rules.

Hi,

If it is only the mobile messages you want to prevent you should be able to just block that address. The mobile transmission will use a different route to the integrations.

Kind regards,

Lee Pinchbeck

Also one of our customers who uses socketlabs.com has a different login for test/dev vs prod; when mails come in to the company server they can sort them by the smtp login used.