diff --git a/azure-pipelines.yml b/azure-pipelines.yml
index 4e452b3..7a4898b 100644
--- a/azure-pipelines.yml
+++ b/azure-pipelines.yml
@@ -3,7 +3,7 @@ pool: 'Hosted VS2017'
 variables:
  - name: spnName
    value: 'pipelines-runner'
- - name: blueprintPath
+ - name: blueprintsPath
    value: '.\samples\'
  - name: blueprintName
    value: '101-boilerplate'
diff --git a/pipelines-scripts/README.md b/pipelines-scripts/README.md
index cff3502..c607771 100644
--- a/pipelines-scripts/README.md
+++ b/pipelines-scripts/README.md
@@ -11,6 +11,8 @@ This directory has two scripts - `build.ps1` and `release.ps1` that collectively
 
 While this is more specific to Azure DevOps pipelines, **the methodolgies and strategies apply just as well to any other release management tool.**
 
+**NOTE:** If you *are* using Azure DevOps Pipelines, we highly encourage you to use Neil Peterson's Azure Blueprints DevOps extension. These are more heavily tested, more fault tolerant, and better maintained than the build/release scripts in this repo.
+
 ## How to use this guide
 The `azure-pipelines.yml` build pipeline definition has variables set up to do a full release on the `101-boilerplate` blueprint. If you want to test a different blueprint, change the varaibles at the top of that file and [change your parameters and test environment](#to-configure-your-release-test) accordingly
 
@@ -21,5 +23,5 @@ This does steps 1 and 2 above. For the most part, this script is pretty straight
 This does steps 3 and 4 above. You can choose to run this in a build pipeline or a release pipeline. If you are solely validating that the blueprint is working as expected, I recommend keeping it in build. If you are planning to do a rollout of a blueprint to dev -> QA -> pre-prod -> prod (or some equivalent), I would recommend using Release Pipelines and using some sort of validation between each release stage.
 
 ### To configure your release test ###
-Each blueprint will have it's own parameters and their own "expected state" for what the environment should look like when it is applied. You will need to update lines `61` to `65` based on the parameters of the blueprint, and you will need to also account for what the test environment looks like between lines `50` and `56`
+Each blueprint will have it's own parameters and their own "expected state" for what the environment should look like when it is applied. You will need to supply your own assignment parameters file which will also need your `blueprintId`.