Skip to main content

Our current process of doing production database refreshes is to turn off the appropriate business rules that involve sending out emails or texts to users in the field. Then, set the phone number and email address fields to NULL via a SQL update.

We want to keep all business rules active and contact information intact, but would like to have something that does not send out communications when testing the business rules in our pre-production environments if we need to fix or change them.

Does anyone have any ideas on to make this process easier and reduce the time to refresh production data into pre-production environments?

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

I’ve done this by setting the external address in the SMTP app params or message routing to an invalid value, for example by add XXX to the address such as smtp.mymailserviceXXX.com.   Then you can see in the server log that FSM attempted to send a message but got the appropriate error.

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.

Reply


Terms & ConditionsCookie settings