---
sourceDocument: Yokohama Build workflows
sourceDocumentLink: https://www.servicenow.com/docs/r/yokohama/build-workflows

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama Build workflows

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# Collect User Data activity

# Collect User Data activity {#ariaid-title1}

Release version: Yokohama  
Updated January 30, 2025  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Collect User Data activity

The Collect User Data activity enables you to gather user inputs during a playbook run for later use within that playbook.
It is primarily suited for scenarios where you don't have an existing table to store data, do not require reporting on the data, and do not need to use the data outside the playbook context.
Show full answer Show less  
Note that starting with the Yokohama 26.1 release, this activity is no longer available for new use from the activity picker. It will continue to function in existing playbooks but new implementations should use the **Questionnaire activity**, which simplifies data collection by not requiring a prior data definition.

## When to Use

* When no pre-existing table exists for data storage
* When reporting on collected data is unnecessary
* When data is only needed within the playbook process

If a table already exists for storing data, it is recommended to use the **User Form activity** instead.

## Key Inputs and Configuration

* **User form for data collection:** The core input, requiring you to create a data definition to specify the data agents or fulfillers will collect during the playbook run.
* **Assignment Group and Assigned To:** Controls user access to submit, view, and edit collected data. If unset, any user can interact with the data. These fields default to the assignment of the trigger record.
* **Wait for user input:** Option to pause the playbook until the user manually completes or skips the activity. Only editable by users with the playbook.admin role.
* **Run conditions and scheduling:** Define when the activity or stage runs, either immediately when the playbook/stage starts or after specific activities/stages complete. You can also add start delays.

## Roles and Availability

This activity is available as a common activity to users with **admin** , **playbook.admin** , or **pdauthor** roles. These users can add this activity to playbooks and configure it.

## Outputs

The activity outputs a reference to the record containing the collected data, accessible via the pill-picker for use in subsequent activities within the playbook. This enables you to utilize collected user inputs dynamically as the playbook progresses.

## Practical Use Cases

* Collecting user-provided information such as shipping addresses to be used later in the playbook (e.g., for generating shipping labels)
* Gathering yes/no responses to influence conditional playbook flows

## Additional Notes

The activity properties panel allows you to configure common activity inputs such as labels, descriptions, and run conditions. The pill-picker assists in dynamically referencing data from prior activities.  
Collects inputs from a user during a playbook run to use later in the playbook.
Important:  
As of the 26.1 release, the Collect user data activity is no longer available in the activity picker. The activity will continue to function wherever it is used, but for new activities use the Questionnaire activity instead. The Questionnaire activity does not require you to create a data definition. To learn more about the Questionnaire activity, see [Questionnaire activity](https://www.servicenow.com/docs/0Zhk1Qtvq62no8BNvPsGbQ "Collects inputs from a user during a playbook run to use later in the playbook.").  
Use the Collect User Data activity if:

* You don't have a table already,
* You don't need to run reports on the collected data,
* And you don't need to use the data outside of the playbook.

{#collect-user-data-activity__ul_egs_1vr_m1c} If you already have a table to store the collected data, use the [User Form activity](https://www.servicenow.com/docs/iL95LMDw3TRy6v21IzMY9Q "Use this activity to surface a record to the end user. This activity requires you to select a table and record, and the desired form view that should be surfaced to the end user in your playbook. The end user can then interact with this record accordingly. Display a form during runtime to collect input values for your playbook.").

The key input for this activity is the User form for data collection field, under the [Inputs](https://www.servicenow.com/docs/gFkko~pPcyRmjJIqz~fzNA#collect-user-data-activity__collect-user-data_inputs) section. To provide this input, you must [create a data definition](https://www.servicenow.com/docs/4KwKWPY3p8NVrI8pisRKBA "Use data definitions to collect and use pieces of information later in a playbook.") first.

## Roles and availability {#collect-user-data-activity__section_pwq_rb5_kcb}

This activity is available as a common activity. Users with the admin, playbook.admin, or pd_author can add this activity to a playbook.  
During a playbook run, you can use data definitions to potentially:

* Collect a shipping address, then reference the address when generating a shipping label.
* Ask the user "yes" or "no" questions, and determine subsequent activities based on the user's responses.
{#collect-user-data-activity__ul_oh4_pfb_j1c}

## Common properties {#collect-user-data-activity__section_yb4_zq3_plb}

These properties are common to all to activities in Playbooks.  
Open the activity properties panel and configure your activity to add values for the following inputs. If the input value varies, use the pill-picker to show where to get the value. To learn more about the pill-picker, see [Dot-walking examples](https://www.servicenow.com/docs/access?context=dot-walking-examples&version=yokohama&pubname=yokohama-platform-user-interface&ft:locale=en-US). {#collect-user-data-activity__table_ajt_sr3_plb__entry__3}

| Input | Type | Description |
|-|-|-|
| Label | String | Title to display as activity and playbook card. |
| Description | String | Information to display about activity usage or outcome. |
| Run condition | Condition Builder | Conditions that must be met to run an activity or stage. You can use data from prior activities to build conditions. Note: Show additional options to see this field. |
| Start Rule | Choice | Under ScheduleStart Rule, select a start rule for when your stage should start running: * When process starts: Your stage starts running as soon as the playbook starts. * After specific stages: Your stage starts running after specified stage(s) have finished running. {#collect-user-data-activity__ul_f4z_nq1_ppb}Under Schedule \> Start Rule, select a start rule for when your activity should start running: <!-- --> * When stage starts: Your activity starts running as soon as its stage starts running. Your stage starts running when your playbook is triggered. * After specific activities: Your activity starts running after specified activities have finished running. {#collect-user-data-activity__ul_zzc_3ls_m1c} |
| Start with delay | True/False | Option to wait for a duration of time before running an activity or stage. When enabled, this input displays the [Start with delay input properties](https://www.servicenow.com/docs/ZO5_TxRewwK7XqnX5otC7A "Specify a duration of time to wait before running an activity or a stage whose start rule and conditions have been met. Give users time to act during automated playbooks. Give users time to wait for a specific date and time to complete actions."). Note: Show additional options to see this field. |
[ ]

{#collect-user-data-activity__table_ajt_sr3_plb}

## Inputs {#collect-user-data-activity__collect-user-data_inputs}

Many of these inputs are common to activities in Playbooks. The key input for this activity is User form for data collection field.  
After configuring the required inputs for your activity, you can also choose to configure additional inputs. In the side panel, select Show additional options to display these advanced inputs. For more information, see [Activity experience](https://www.servicenow.com/docs/r014Lhz_11xoMRZZRHOzcA#activity-definitions__activity-experience). {#collect-user-data-activity__table_cjj_sr3_plb__entry__3}{#collect-user-data-activity__wait-process}

| Input | Type | Description |
|-|-|-|
| Assignment Group for this Process Step | Reference.Group \[sys_user_group\] | Assignment group allowed to perform this playbook activity. If you don't set any values for Assignment Group or Assigned To, any user can read and edit the collected data. The Assignment group and Assigned to fields limit who has access to do so. To specify only individual users, use the Assigned To field. The same users do not need to be specified in both fields. Note: By default, these fields are mapped to the Assignment Group and Assigned To fields of the trigger record. This means that users assigned to work on the parent record have access to submit, view and edit the collected data by default. |
| Assigned to this Process Step | Reference.User \[sys_user\] | User allowed to perform this playbook activity. If you don't set any values for Assignment Group or Assigned To, any user can read and edit the collected data. The Assignment group and Assigned to fields limit who has access to do so. To specify only individual users, use the Assigned To field. The same users do not need to be specified in both fields. Note: By default, these fields are mapped to the Assignment Group and Assigned To fields of the trigger record. This means that users assigned to work on the parent record have access to submit, view and edit the collected data by default. |
| User form for data collection | Choice | Type of input form used to collect data. Playbook authors define the data that they want agents or fulfillers to collect during a playbook run in the `sys_flow_data_definition` table. When the information is collected, it is stored in the `sys_flow_data` table for use later in the playbook run, instead of in the record table. To define the data you want an agent or fulfiller to collect, see [Create a Data Definition](https://www.servicenow.com/docs/4KwKWPY3p8NVrI8pisRKBA "Use data definitions to collect and use pieces of information later in a playbook."). |
| Wait for user input | Choice | Option to pause the playbook until the end user manually completes or skips the activity. Only users with the playbook.admin role can edit this field. By default, the activity waits for user action or data before it completes. |
[ ]

{#collect-user-data-activity__table_cjj_sr3_plb}

## Additional properties {#collect-user-data-activity__section_yjr_tzs_m1c}

Move stuff here.

## Outputs {#collect-user-data-activity__section_unx_fr3_plb}

These outputs can provide data to other activities in your playbook. You can access this data as activity inputs when you configure your activity: {#collect-user-data-activity__table_mv2_rr3_plb__entry__3}

| Output | Type | Description |
|-|-|-|
| Record | Reference.Flow Data | Reference to record containing collected data. Use the pill-picker to dot-walk to OutputsRecordVars to see all collected data. To learn more about the pill-picker, see [Dot-walking examples](https://www.servicenow.com/docs/access?context=dot-walking-examples&version=yokohama&pubname=yokohama-platform-user-interface&ft:locale=en-US). |
[ ]

{#collect-user-data-activity__table_mv2_rr3_plb}

## UI Layouts {#collect-user-data-activity__id_xrs_lww_41c}

Set properties for how the activity renders during a playbook run.  

*[\>]: and then