This issue isn't an obvious one, so I will explain to provide a little more context:
Bamboo's "Run Customized" feature is very useful when dealing with multi-repo configurations. Suppose a build requires 6 different git repos in order to run, and a developer needs to make related changes in several repos. The changes are pushed to feature branches in each repo for the purpose of code review. The developer has tested the changes on his/her local machine, and wants to execute a Bamboo build that will push a notification to the code review that the build passes. The branches cannot be merged to master yet because the code reviews are not completed.
With a single Bamboo job using branch detection, Bamboo may detect one of the feature branches on whatever repository is configured as the default. If the build is hardcoded to use the master branch of the other repos, then the build of the feature branch fails because the change depends on the other simultaneous changes in the other feature branches in the related repos. This is annoying because as Bamboo pushes a "Build Failed" notification to the code review, and there is no way to clear it other than obtaining a pass from the same build plan. If the build failure occurred on a Bamboo branch that is later automatically cleaned up (eg. due to inactivity) then the failure is stuck on the code review, and the developer has to get Bitbucket admin permissions to bypass the "no failed builds" requirement to merge the code review.
One way to work around this is to use Plan Variables that define the branch for each repository used in the build, with a default value of "master" (eg. Repo1Branch=master, Repo2Branch=master and so on...). When a developer needs to make a messy multi-repo feature change, they can "Run Customized" and override any/all of the plan variables to target the desired branch configuration. For example:
Repo1Branch=myFeatureBranch
Repo2Branch=myFeatureBranch
Repo3Branch=myFeatureBranch
Repo4Branch=master
Repo5Branch=master
Repo6Branch=master
The build checks out the correct code, passes the build, and pushes appropriate "Build Passed" notifications to each of the code reviews! Excellent 
However, due to this issue, a second ghost build is triggered immediately afterward. Commit detection tells us Author=Unknown committed something git doesn't recognize, and not surprisingly, it fails to build. Here's an example from a recent build I did:
[unknown] Yesterday 6a3b34ee098c1ce35482d729fa83400371969614
Bamboo was unable to extract changes between revision 77e455d7c1e5ec63f600a21b1065ab275960baa1 and 6a3b34ee098c1ce35482d729fa83400371969614.
The suggested workaround is removing all Triggers from the build. This means developers must run builds manually, which is inconvenient for the 90% of code reviews that aren't messy multi-repo feature changes.
Better workaround:
That seems to stop the system from overwriting the custom build until an actual change occurs in the code repo