Minor content/text updates

Author: craigshoemaker

articles/static-web-apps/apis.md

@@ -20,16 +20,7 @@ Azure Static Web Apps provides serverless API endpoints via [Azure Functions](..
 
 ## Configuration
 
-API endpoints are available to the web app through the _api_ route. While this route is fixed, you have control over the folder where you locate the associated Azure Functions app. You can change this location by editing the workflow YAML file located in your repository's _.github/workflows_ folder.
-
-Set the the following location's value to the desired folder location for the API app in your repository.
-
-```schema
-jobs
-└── steps
-  └── with
-    └── api_location
-```
+API endpoints are available to the web app through the _api_ route. While this route is fixed, you have control over the folder where you locate the associated Azure Functions app. You can change this location by [editing the workflow YAML file](github-actions-workflow.md#build-and-deploy) located in your repository's _.github/workflows_ folder.
 
 ## Constraints
 
@@ -38,6 +29,7 @@ Azure Static Web Apps provides an API through Azure Functions. The capabilities
 - The API route prefix is must be _api_.
 - Triggers and bindings are limited to [HTTP](../azure-functions/functions-bindings-http-webhook.md).
   - All other [Azure Functions triggers and bindings](../azure-functions/functions-triggers-bindings.md#supported-bindings) except for output bindings are restricted.
+- Logs are only available if you add [Application Insights](../azure-functions/functions-monitoring.md) to your Functions app.
 
 ## Next steps
 

articles/static-web-apps/github-actions-workflow.md

@@ -139,7 +139,7 @@ The `repo_token`, `action`, and `azure_static_web_apps_api_token` values are set
 
 ## Customizations
 
-There are few additional configuration settings available that are not generated in the workflow file by default.
+There are few additional configuration settings available that are not generated in the workflow file by default. The following customizations can be defined under a job's `with` section.
 
 ### Custom build commands
 
@@ -149,7 +149,7 @@ The deployment always calls `npm install` before any custom command.
 
 | Command            | Description |
 |---------------------|-------------|
-| `app_build_command` | Defines a custom command to run during deployment of the static content application.<br><br>For example, to configure a production build for an Angular application enter `ng build -prod`.  |
+| `app_build_command` | Defines a custom command to run during deployment of the static content application.<br><br>For example, to configure a production build for an Angular application enter `ng build -prod`. If left blank, the workflow tries to run the `build` or `build:Azure` commands.  |
 | `api_build_command` | Defines a custom command to run during deployment of the Azure Functions API application. |
 
 ### Route file location

articles/static-web-apps/review-publish-pull-requests.md

@@ -13,19 +13,22 @@ ms.author: yolasors
 
 This article demonstrates how to use pre-production environments to review changes to applications deployed with [Azure Static Web Apps](overview.md).
 
-
-A pre-production (staging) environment is a fully-functional staged version of your application that includes changes not available in production. 
+A pre-production (staging) environment is a fully-functional staged version of your application that includes changes not available in production.
 
 Azure Static Web Apps generates a GitHub Actions workflow in the repository. When a a pull request is created against a branch that the workflow watches, the pre-production environment is built. The pre-production environment stages the app, enables you to perform reviews before pushing to production.
 
 Multiple pre-production environments can co-exist at the same time when using Azure Static Web Apps. Each time you create a pull request against the watched branch, a staged version with your changes is deployed to a distinct pre-production environment.
 
 There are many benefits of using pre-production environments. For example, you can:
-- Review visual changes between production and staging - for example, updates to content and layout
-- Demonstrate the changes to your team
-- Compare different versions of your application
-- Validate changes using acceptance tests
-- Perform sanity checks before deploying to production
+
+- Review visual changes between production and staging. For example, viewing updates to content and layout.
+- Demonstrate the changes to your team.
+- Compare different versions of your application.
+- Validate changes using acceptance tests.
+- Perform sanity checks before deploying to production.
+
+> [!NOTE]
+> During preview, a [maximum of only one staging environment](quotas.md) is allowed at a time.
 
 ## Prerequisites
 
@@ -42,7 +45,7 @@ Begin by making a change in your repository. You can do it directly on GitHub as
     Type a branch name and click on **Create branch**.
 
 1. Go to your _app_ folder and change some text content. For example, you can change a title or paragraph. Once you found the file you want to edit, click on **Edit** to make the change.
-    
+
     :::image type="content" source="./media/review-publish-pull-requests/edit-file.png" alt-text="Edit file button in GitHub interface":::
 
 1. After you make the changes, click on **Commit changes** to commit your changes to the branch.
@@ -54,18 +57,20 @@ Begin by making a change in your repository. You can do it directly on GitHub as
 Next, create a pull request from this change.
 
 1. Open the **Pull request** tab of your project on GitHub:
+
     :::image type="content" source="./media/review-publish-pull-requests/tab.png" alt-text="Pull request tab in a GitHub repository":::
 
 1. Click on the **Compare & pull request** button of your branch.
 
 1. You can optionally fill-in some details about your changes, then click on **Create pull request**.
+
     :::image type="content" source="./media/review-publish-pull-requests/open.png" alt-text="Pull request creation in GitHub":::
 
 You can assign reviewers and add comments to discuss your changes if needed.
 
 > [!NOTE]
 > You can make multiple changes by pushing new commits to your branch. The pull request is then automatically updated to reflect all changes.
- 
+
 ## Review changes
 
 After the pull request is created, the [GitHub Actions](https://github.com/features/actions) deployment workflow runs and deploys your changes to a pre-production environment.
@@ -80,7 +85,7 @@ If you take a closer look at the URL, you can see that it's composed like this:
 
 For a given pull request, the URL remains the same even if you push new updates. In addition to the URL staying constant, the same pre-production environment is reused for the life of the pull request.
 
-## Publish changes 
+## Publish changes
 
 Once changes are approved, you can publish your changes to production by merging the pull request.
 
@@ -103,6 +108,5 @@ The number of pre-production environments available for each app deployed with S
 
 ## Next steps
 
-
 > [!div class="nextstepaction"]
 > [Setup a custom domain](custom-domain.md)

articles/static-web-apps/routes.md

@@ -36,7 +36,9 @@ The following table lists the appropriate location to put your _routes.json_ fil
 
 ### Angular
 
-Angular apps do not copy files in the _src_ folder to the artifact folder by default. Use the following steps to ensure the _routes.json_ is copied to the appropriate location.
+Angular apps do not copy files in the _src_ folder to the artifact folder by default. You can point the GitHub Actions workflow directly to your _routes.json_ file via the [`routes_location` workflow customization](github-actions-workflow.md#route-file-location), or you can update the _angular.json_ file to copy the file.
+
+Using the `routes_location` customization is preferred, but you can also use the following steps update the _angular.json_ file.
 
 1. In Visual Studio Code, open the _angular.json_ file
 1. Go to the property at: