When sending a client file to iSystems support, one key question is: scrambled or not? This is supposed to be specified every time support asks, and the distinction is important.

This blog post clarifies what this is all about.

The purpose of a scrambled database is to obscure sensitive employee / banking information such that if the file somehow went astray outside the secure Evolution ecosystem, it would limit the damage of disclosure. In practice, this is likely as much CYA for iSystems to minimize their risk/liability of having sensitive customer data when it's not necessary.

This is all a really good idea to reduce the risk of inadvertent information disclosure, and this is likely what you should assume if they don't specify one way or another.

BUT: a scrambled database cannot be fixed and sent back to you, because the scrambled data would destroy your real data when you restore it to your production environment.

When to scramble or not

Generally, files are expected to be sent scrambled unless there's a good reason not to, and there are two good reasons not to:

1. iSystems is researching a problem directly related to the fields that are scrambled, so they need to see the original data
2. iSystems intends to repair the database and send it back to you

The latter is fairly common, and it should be obvious that restoring a "repaired" scrambled database into production would destroy that client: all the social security and banking numbers would be bogus.

In practice, files are typically sent up scrambled at first, and if they really do need to fix something, they will ask for it again, but unscrambled. Alternately, they can provide a fix by sending some SQL statements to run against the database without having to send the file itself back.

Putting to-be-fixed clients on hold

Sending a scrambled database can be done anytime without worrying about production, because it's strictly a copy that's sent, but when sending an unscrambled database that's to be fixed, we have to insure that nobody makes changes to the local database while iSystems has a copy up there.

While an unscrambled database is sitting at support for repair, if the payroll client makes changes (say, adding an employee) to the local copy at the service bureau, this new EE would be lost when the fixed database was sent back to the SB and restore into production.

To avoid this, one can put a client database on hold while the database is in the shop, and there are a few ways to accomplish this. The details are for another post, but putting the client in readonly mode or maintenance hold (from within Evolution) is likely to take care of this properly.

What data is scrambled?

This is information I've derived from looking at sample databases, and may not be complete. This is not authoritative from iSystems.

• The field CL.CL_NBR has 600000000 added to it, so client #123 becomes 600000123
• The field CO.FEIN is set to 100000001
• The field CL.NAME has "SCRAMBLED: " added to the front, so "Steve's Bait Shop" becomes "SCRAMBLED: Steve's Bait Shop", with the result truncated to the maximum 40-character length of this field.
• The field CL_PERSON.SOCIAL_SECURITY_NUMBER is set to a random value. I heard a rumor that Evo will consult TMP_TBLS and make sure the selected random number is not already in used by another actual employee at any company in this service bureau. I have not confirmed this.
• The field CL_BANK_ACCOUNT.CUSTOM_BANK_ACCOUNT_NUMBER is set to a scrambled random value.
• The field EE_DIRECT_DEPOSIT.EE_BANK_ACCOUNT_NUMBER is set to a scrambled value.
• In audit history, the old values for EE_DIRECT_DEPOSIT.EE_BANK_ACCOUNT_NUMBER and CL_BANK_ACCOUNT.CUSTOM_BANK_ACCOUNT_NUMBER are set to 99999999

There may be other transformations, but I haven't seen them yet and will update this post as I discover them.

File / Client numbers for scrambled databases

In order to be really sure that a scrambled database is not mistaken for a real one — which, as noted, would destroy that client's data in production — all scrambled clients have their internal CL# set to a really high number in the range 6000XXXXX, both in the filename and internally in the databse itself.

If you ever see a database in the form CL_600000123.gdb in your /db/evolution/ path, or as an internal number while in the Evo client selection window, it means that somebody restored a scrambled database to production, probably in error.