It may be the case that you cannot define all playbook information up front.
We have the option to define different parameters using variables; however,
for someone with little or no experience with JSON or YAML syntax,
we need a different approach.
Also, there are requirements set for role‑based access. There may be some
users who only have been granted the read role on the template and may not
be able to edit that template definition.
This includes a definition of variables. Here Ansible Tower has
a useful feature called surveys. An Ansible Tower survey is a
feature that could be used to populate the variables every time
a template is executed.
A survey is essentially a questionnaire defined by a system
administrator that asks for input in a user‑friendly manner where simple
user input validation is performed. Once validated,
the entered values are stored in Ansible variables, just as if they
would have been defined in YAML or JSON format.
So in Ansible Tower we have a job template survey, that makes it much
easier to input variables when a job is started.
Can you recall when we discussed variables in the first module and that
variables specified Ansible but have different levels of precedence? Well
variables from a survey have the highest priority.
So surveys allow users to be prompted at launch with questions about the job.
This allows for variables to be defined that affect
the playbook run at launch time.
So we have job types of run and check, that will provide a way to set
up surveys in the job template creation or editing.
So surveys set extra variables for the playbook,
like prompt for extra variable does, but in a user‑friendly
question‑answer way. So surveys allow for validation of user input.
So consider a survey as like a popup similar to a prompt on
demand, except we configure what those popups are.
So as a last key point before we enter the demo, surveys should be
combined with RBAC, so we have a certain group that are allowed to self
drive and another group with minimal access.