Updated: May 27
Flush cache, Active, and Run once columns have been removed. This article originally spoke to using the Active field, I'm leaving the article as is for those not on Quebec and historical purposes.
The Run Fix Script button got an upgrade during Quebec too, so many sure you're not running on old Paris code due to overlooking a skip and it's checking for 'Active' fix scripts because that column doesn't exist anymore.
This post is just a quick tip I came across when using application installs and Fix Scripts. This post speaks to the functionality of installing or upgrading an application from either the Application Repository or Store and not Update Sets.
There are a couple of fields to be mindful of on the Fix Script table, that can assist you when doing an application install or upgrade.
Scenario 1: You have a Fix Script that are marked as Active and Run Once but has not yet been installed on the target instance will automatically run during the Application install/upgrade after the application installs (by default).
Why is this important to know? Imagine you have a Fix Script to correct some data and it takes 1-2+ hours, the Fix Script runs during the application install/upgrade and not in the background, meaning no other application installs can occur during that time. This can be a problem if you work in a larger enterprise that have multiple application installs scheduled as part of its process.
This is important to consider when installing/upgrading an application with Fix Scripts to a Production environment (and the Fix Script does not exist on the target instance yet), as you may want to run Fix Scripts during a lower traffic time, or off hours, yet want the application install to occur during business hours, and don't necessarily need the Fix Script to correspond with the application install/upgrade right away, i.e. updating data/records/etc.
I'm going to put a caveat here, and say this is really up to your process and who is promoting your code, as the Fix Script does have to be set to Active in the target instance before it can be run on demand.
Update: Here's some workarounds to run Fix Scripts during application installs/upgrades that won't lengthen install time and interfere with other application installs that Chris Nanda at GlideFast informed me about.
If your Fix Script doesn't need to be run in process, i.e. doesn't need to occur before other installs happen, one can fire an event from the Fix Script and use a Script Action to do the work in the background scheduler.
Or create a Scheduled Job that is On Demand and uses gs.executeNow from the Fix Script
Tip within a Tip: Always test your Fix Scripts on a Sub-Production environment before installing them to Production and I'm even going to go as far to say even before you install them to your Testing instance. It's vital to know how the Fix Script alters data, and how long the Fix Script takes to run. This will prevent headaches and email threads in the future.
Scenario 2: Your Fix Script has already been deployed to the target instance, and it doesn't need to run again during an application upgrade. For this scenario, make sure the Run Once checkbox is checked, as this will prevent the Fix Script from running again during application upgrade.
Scenario 3: You want the Fix Script to run during every application upgrade. Make sure the Run Once box is unchecked, and the Active field is checked.
Scenario 4: You either want the Fix Script to run once, or every upgrade, but at least you want it to run on application install/upgrade but you want it to run before the application install/upgrade occurs. Make sure you check the Before box to ensure the Fix Script runs before the application upgrade occurs, as this field is unchecked by default.
I hope this helps anyone working with application installs/upgrades out there!