I just worked on a similar setup where I do not want PR builds to run as a result of Scans. The solution that worked for me was to configure the buildStrategies like this:

                buildStrategies {
                    buildRegularBranches()
                    buildChangeRequests {
                        ignoreTargetOnlyChanges true
                        ignoreUntrustedChanges false
                    }
                }

I am trying to get our setup to a point where it won't start ANY builds on initial scans (PRs, branches, or tags) - I only want builds triggered by webhooks (on PR/branch/tag changes or creation).

But I'm not having much success - if I take out the "index" settings in the branch source plugin, the project/repo shows as disabled.

Even though I limit branch names to "named branches" containing master, it still tries to build all branches.

Even though I Iimit tags to only the ones newer than 2 days, it still tries to build all old tags.

I agree and +1. 

Really the problem here is initial branch indexing == any future indexing that finds branches/PRs due to  missing event deliveries isn't it?  This is what needs to change first before this plugin can do it properly.  Its a perfectly valid case to say - "initial indexing should store all current commit ids and I dont want those to build.  But after that initial indexing, I want the newly discovered branches/PRs with any further indexing (scheduled) to be built.  This may be because the events were dropped due to networking/etc..."

The output of this feature should be -

• On initial indexing of a repository - change build cause to "Initial Branch Indexing"
• When skipInitialBuildOnFirstBranchIndexing is enabled - skip all builds that have a cause of "Initial Branch Indexing".  Store the commit id as the current commit.
• When another indexing happens - use a different build cause "Scheduled Branch Indexing" and if commit id is different than current start build.
• When an event comes in - process as normal - starting a build if commit id is different.

Other use case this handles:

• Imagine I have a jenkins production deployed
• Imagine I want to redeploy it.  But I dont want any builds to run.  I just want the new jenkins to find all current branches and all current commit ids. (all part of intial indexing)

Can you achieve this with "suppress automatic SCM triggering" ? 

https://github.com/jenkinsci/branch-api-plugin/blob/master/docs/user.adoc#suppress-automatic-scm-triggering

I just tried it and creates branches from a branch scan but does not trigger the build step. What the documentation fails to explain is whether the interferes with OTHER SCM triggers.

I guess that as other SCM changes will apply to the individual branches not the top level, they can still build. But I might be wrong! It will also probably depend on how you trigger your builds as to whether this works for you...

In my case, I'm using Bitbucket and this is my conf 

properties {    
  suppressFolderAutomaticTriggering {        
    // Defines a regular expression of branch names which will be triggered automatically, for example (?!        
    branches("")        
    // Determines events for which branches with matched names should not be triggered automatically.        
    // Possible values for value:        
    //     'INDEXING'        
    //     'EVENTS'        
    //     'NONE'        
    strategy('INDEXING')    
  }  
}

Just to add to this, as I had trouble finding an answer to this problem; in multibranchPipelineJob's, this is instead defined under branchSources, even though it is visible and acceptable for properties.

multibranchPipelineJob('example') {
    ...
    branchSources {
        branchSource {
            ...
            strategy {
                allBranchesSame {
                    props {
                        suppressAutomaticTriggering {
                            strategy('NONE')
                            triggeredBranchesRegex('^$')
                        }
                    }
                }
            }
        }
    }
...

Note that both the properties and the parameters is ever so slightly different.