# Where is the documentation for register projections and "\_task"? **URL:** \ **Category:** Get Help\ **Tags:** ansible-core\ **Created:** [June 17, 2026, 3:07pm UTC](https://forum.ansible.com/t/where-is-the-documentation-for-register-projections-and-task/45934 "2026-06-17T15:07:06Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![bvitnik](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bvitnik/32/4132_2.png) [@bvitnik](https://forum.ansible.com/u/bvitnik)\ **Post date:** [June 17, 2026, 5:19pm UTC](https://forum.ansible.com/t/where-is-the-documentation-for-register-projections-and-task/45934/2 "2026-06-17T17:19:51Z")
How about this? > > > \## SUMMARY > > \### Register Projections > > The functionality of the \`register\` ke…yword has been expanded to allow registration of multiple variables and inline manipulation of task output with Jinja expressions ("projections"). > > In addition to the existing \`register: varname\` form, the \`register\` keyword can accept a dictionary of \`varname: expression\` pairs (see examples below). > > A new \`\_task\` implicit variable provides Jinja expressions access to the current task's result via its \`result\` property. Expressions under looped tasks can also now access all completed loop results and preview the final loop task result via the \`\_task.loop\_result\` property. The new \`\_task\` implicit variable is available to expressions in \`register\` and task conditionals (\`changed\_when\`, \`failed\_when\`, etc.). Registered variable values are updated and available to task conditional expressions as before, but task conditionals can now bypass \`register\` entirely by accessing \`\_task\` directly (for tasks that do not otherwise require persistence of their result). > > This functionality can simplify and declutter playbooks by allowing common patterns like "Run a task, > register the output, pick out small parts of the output with \`set\_fact\`" to be folded directly into the task itself. Further, because the new \`register\` form is always a Jinja expression, template delimiters (\`{{ }}\`) are not required for dynamic behavior as they were with \`set\_fact\`. > > Unlike \`set\_fact\`, variable registration expressions \*can\* refer to other variable expressions within the same task, and because they are evaluated lazily, can be defined in any order under \`register\` . > > > \### Action APIs for creating dynamic hosts/groups/vars > > A new \`register\_host\_variables\` public API method on \`ActionBase\` allows user action plugins to implement variable-setting functionality that was previously restricted to built-in actions or required risky use of undocumented/internal action result values. > > (TBD: expand description, usage examples) > > The following built-in actions have been modified to use the new API: > \* \`set\_fact\` > \* \`include\_vars\` > > > \## REGISTER PROJECTION EXAMPLES > > \#### Registering multiple variables from a task > > \*\*Before register-projections\*\* > > \`\`\`yml > \- shell: echo hello > failed\_when: echo\_result.stdout is contains "goodbye" > register: echo\_result > > \- set\_fact: > echo\_duration: "{{ echo\_result.delta }}" > capitalized\_result: "{{ echo\_result.stdout | capitalize }}" > \`\`\` > > \*\*After register-projections\*\* > > \`\`\`yml > \- shell: echo hello > failed\_when: \_task.result.stdout is contains "goodbye" > register: > echo\_result: \_task.result # The old register behavior > echo\_duration: \_task.result.delta > capitalized\_result: \_task.result.stdout | capitalize > \`\`\` > > \#### Advanced templating and chaining variable manipulation > > \*\*Before register-projections\*\* > > \`\`\`yml > \- shell: echo hello > register: echo\_output > > \- set\_fact: > start\_hour: "{{ echo\_output.start | regex\_search('\\\\s(\\\\d{2}):\\\\d{2}:\\\\d{2}', '\\\\1') | first | int}}" > > \- set\_fact: > output\_message: "{{ echo\_output.stdout \* start\_hour }}" > \`\`\` > > \*\*After register-projections\*\* > > \`\`\`yml > \- shell: echo hello > register: > output\_message: \_task.result.stdout \* start\_hour # Notice that start\_hour is defined below, but can still be used! The order that they're declared does not matter. > start\_hour: \_task.result.start | regex\_search('\\\\s(\\\\d{2}):\\\\d{2}:\\\\d{2}', '\\\\1') | first | int > \`\`\` > > \#### Using \`failed\_when\` without a register > > \*\*Before register-projections\*\* > > \`\`\`yml > \- shell: echo hello > failed\_when: echo\_result.stdout is contains "goodbye" > register: echo\_result > \`\`\` > > \*\*After register-projections\*\* > > \`\`\`yml > \- shell: echo hello > failed\_when: \_task.result.stdout is contains "goodbye" > \`\`\` > > \#### Registering single loop items > > \*\*Before register-projections\*\* > > \`\`\`yml > \- shell: echo {{ item }} > loop: > - 1 > - 2 > register: echo\_loop\_result > > \- set\_fact: > second\_echo\_stdout: "{{ echo\_loop\_result.results\[1\].stdout }}" > \`\`\` > > \*\*After register-projections\*\* > > \`\`\`yml > \- shell: echo {{ item }} > loop: > - 1 > - 2 > register: > second\_echo\_stdout: \_task.loop\_results\[1\].stdout | default(0) # using default here is necessary as when the loop is on the first item, it will still try and access \`loop\_results\[1\]\` which doesn't exist yet > \`\`\` > > \##### ISSUE TYPE > > \- Feature Pull Request And some forum discussion here also: > [@Fallible 2025.12.5 released with Register Projections and new Action API previews](https://forum.ansible.com/t/fallible-2025-12-5-released-with-register-projections-and-new-action-api-previews/44965): > > We’re happy to announce a new drop of the fallible experimental Ansible build, and are looking for your feedback! This one contains previews of a couple of features currently slated for release in Ansible Core 2.21: Register Projections allows the register keyword to set multiple vars using the result of arbitrary Jinja expressions. It adds a new implicit variable (\_task) for the register keyword and task conditionals (e.g., failed\_when, changed\_when, break\_when, until) to directly access the … --- _[View the full topic](https://forum.ansible.com/t/where-is-the-documentation-for-register-projections-and-task/45934)._