Update docs to reflect field removals

1 files changed, 11 insertions, 17 deletions

diff --git a/docs/prompting.md b/docs/prompting.md
index a1612657b9..bbc0dc1b51 100644
--- a/docs/prompting.md
+++ b/docs/prompting.md
@@ -21,7 +21,7 @@ The standard pattern applies to fields
  - `diff_mode`
  - `verbosity`
 
-##### Non-Standard Cases (Credentials Changing in Tower 3.3)
+##### Non-Standard Cases
 
  - `ask_variables_on_launch` allows unrestricted use of
    - `extra_vars`
@@ -30,9 +30,7 @@ The standard pattern applies to fields
  - Enabled survey allows restricted use of
    - `extra_vars`, only for variables in survey (with qualifiers)
  - `ask_credential_on_launch` allows use of
-   - `credential`
-   - `vault_credential` / `extra_credentials` / `credentials`
-     (version-dependent, see notes below)
+   - `credentials`
  - `ask_inventory_on_launch` allows use of
    - `inventory`
 
@@ -42,16 +40,12 @@ spec to exist and `survey_enabled` to be true). On the other hand,
 if `ask_variables_on_launch` is true, users can provide any variables in
 extra_vars.
 
-_(supported, but deprecated)_ Prompting enablement for several types of
-credentials is controlled by a single
-field. On launch, multiple types of credentials can be provided in their respective fields
-inside of `credential`, `vault_credential`, and `extra_credentials`. Providing
-credentials that require password input from the user on launch is
-allowed, and the password must be provided along-side the credential, of course.
-
-If the job is being spawned using a saved launch configuration,
-all credential types are managed by a many-to-many relationship
-called `credentials` relative to the launch configuration object.
+Prompting enablement for all types of credentials is controlled by `ask_credential_on_launch`.
+Clients can manually provide a list of credentials of any type, but only 1 of _each_ type, in
+`credentials` on a POST to the launch endpoint.
+If the job is being spawned by a saved launch configuration (such as a schedule),
+credentials are managed by the many-to-many relationship `credentials` relative
+to the launch configuration object.
 The credentials in this relationship will either add to the job template's
 credential list, or replace a credential in the job template's list if it
 is the same type.
@@ -69,9 +63,9 @@ actions in the API.
    - can accept certain fields, with no user configuration
 
 When launching manually, certain restrictions apply to the use of credentials
- - if providing any of `credential`, `vault_credential`, and `extra_credentials`
-   this becomes the "legacy" method, and imposes additional restrictions on
-   relaunch, and is mutually exclusive with the use of `credentials` field
+ - if providing deprecated `extra_credentials` this becomes the "legacy" method,
+   and imposes additional restrictions on relaunch,
+   and is mutually exclusive with the use of `credentials` field
  - if providing `credentials`, existing credentials on the job template may
    only be removed if replaced by another credential of the same type
    this is so that relaunch will use the up-to-date credential on the template