AnsiblePilot — Master Ansible Automation

AnsiblePilot is the leading resource for learning Ansible automation, DevOps, and infrastructure as code. Browse over 1,400 tutorials covering Ansible modules, playbooks, roles, collections, and real-world examples. Whether you are a beginner or an experienced engineer, our step-by-step guides help you automate Linux, Windows, cloud, containers, and network infrastructure.

Popular Topics

About Luca Berton

Luca Berton is an Ansible automation expert, author of 8 Ansible books published by Apress and Leanpub including "Ansible for VMware by Examples" and "Ansible for Kubernetes by Example", and creator of the Ansible Pilot YouTube channel. He shares practical automation knowledge through tutorials, books, and video courses to help IT professionals and DevOps engineers master infrastructure automation.

Build an AAP Self-Service Template: After Hours Branch Access Report

By Luca Berton · Published 2024-01-01 · Category: security-compliance

Learn how AAP 2.7's Automation Portal turns a branch access-report playbook into a one-click self-service template for non-technical operators.

Why "After Hours Access" Deserves Its Own Template

At Red Hat Tech Day Netherlands 2026 in Bunnik, Fred van Zwieten and Ismail Dhaoui walked the audience through the new Automation Portal in Ansible Automation Platform (AAP) 2.7. The headline feature is a self-service template gallery: instead of asking an automation engineer to find a playbook, check its extra vars, and launch it from the controller UI, an operator picks a tile from a catalog and presses Start. The platform handles everything else — inventory scoping, credentials, and safe defaults.

Among the templates shown live in the branch-operations section of the catalog was Branch - After Hours Access Report, sitting next to Branch - Network Health Check and Branch - WiFi Reset. Its job is narrow and useful: scan access logs for a given branch and surface any activity that happened outside normal operating hours — a door badge swipe, a VPN login, or an administrative console session logged at 2 a.m. when the store or office should be empty.

This article breaks down what that template looks like under the hood, why it's a good first candidate for self-service, and how you'd structure the underlying playbook so it's safe to expose to non-engineers.

See also: Build an AAP Self-Service Template: Backup Network Switch Configs to Git

What the Template Does From the Operator's Seat

In the Automation Portal demo, the operator experience is deliberately shallow:

  1. Open the branch operations section of the template gallery.
  2. Click the Branch - After Hours Access Report tile.
  3. Select (or confirm) the branch/site from a prompted survey field.
  4. Click Start.
  5. Receive a report — job output, an artifact, or a notification — without ever touching an inventory file, a credential, or the underlying playbook path.
That simplicity is the entire point of the Automation Portal. The complexity — which log sources to query, what counts as "after hours," how to format the report, who gets notified — is encoded once by the automation team and reused every time the tile is clicked.

Anatomy of the Underlying Job Template

Behind that single Start button sits a normal AAP job template, the same object type that has always existed in the controller. What changes with the Automation Portal is discoverability and packaging, not the execution engine. A reasonable structure for this template's job template configuration looks like this:

SettingPurpose
Playbookbranch-after-hours-access-report.yml
InventoryDynamic branch inventory (scoped by survey answer)
CredentialsRead-only credential for access/log systems
SurveyPrompts for branch/site name and optional date range
Execution EnvironmentEE containing log-query and reporting collections
NotificationsEmail/Slack notification with the generated report attached
Concurrent jobsAllowed (multiple operators can run it for different branches)
Because the job template is read-only against production systems — it queries logs, it doesn't change firewall rules or reset anything — it's a low-risk, high-value first template to publish into the self-service gallery, which is likely why Red Hat used it as one of the flagship "Branch" examples in the demo.

See also: Build an AAP Self-Service Template: Branch Network Health Check

Example Playbook Structure

Here is an illustrative playbook you could register behind the tile. It queries an access-control or authentication log source, filters for events outside the branch's configured operating hours, and emits a report artifact:

---
- name: Branch - After Hours Access Report
  hosts: branch_gateways
  gather_facts: false
  vars:
    operating_hours_start: "07:00"
    operating_hours_end: "20:00"
    report_path: "/tmp/reports/{{ branch_name }}-after-hours-{{ ansible_date_time.date }}.json"

  tasks:
    - name: Collect access log events for the branch
      ansible.builtin.uri:
        url: "https://{{ access_api_host }}/v1/branches/{{ branch_name }}/access-events"
        method: GET
        headers:
          Authorization: "Bearer {{ access_api_token }}"
        return_content: true
      register: access_events

    - name: Filter events outside operating hours
      ansible.builtin.set_fact:
        after_hours_events: >-
          {{ access_events.json.events
             | selectattr('time', 'lt', operating_hours_start)
             | list
             + access_events.json.events
             | selectattr('time', 'gt', operating_hours_end)
             | list }}

    - name: Write after-hours report artifact
      ansible.builtin.copy:
        content: "{{ after_hours_events | to_nice_json }}"
        dest: "{{ report_path }}"
      delegate_to: localhost

    - name: Notify security channel when after-hours events are found
      community.general.slack:
        token: "{{ slack_token }}"
        channel: "#branch-security"
        msg: >-
          After-hours access report for {{ branch_name }}:
          {{ after_hours_events | length }} event(s) found outside
          {{ operating_hours_start }}-{{ operating_hours_end }}.
      when: after_hours_events | length > 0

This is a plausible shape for the real template, not a documented API — Red Hat's Tech Day session showed the catalog tile and the Start-button experience, not the playbook internals, so treat the task names and variables above as illustrative scaffolding you'd adapt to your own access-control and logging systems.

Three properties make "After Hours Access Report" a strong self-service candidate:

  • Read-only blast radius. It queries and reports; it doesn't remediate. That makes it safe to hand to security analysts, branch managers, or helpdesk staff who aren't Ansible engineers.
  • Repeatable, parameterized shape. The only real input is "which branch and, optionally, which date range" — a perfect fit for a short survey rather than a complex extra-vars form.
  • High-frequency, low-effort need. Compliance and security teams often want this exact report on demand, not just on a schedule, which is precisely the itch the Automation Portal's one-click model is designed to scratch.
Contrast that with Network - Firewall Remediation or CVE Patch from the same catalog shown at the event — those carry real change risk and are better suited to approval workflows layered on top of the same self-service mechanism, something Red Hat also demonstrated with the Network - Firewall Rule Request template.

See also: Build an AAP Self-Service Template: Branch WiFi Reset Playbook

Key Takeaways

  • AAP 2.7's Automation Portal, demoed at Red Hat Tech Day Netherlands 2026, exposes existing job templates as one-click self-service tiles — the automation itself is unchanged, only its packaging and discoverability improve.
  • Branch - After Hours Access Report is a read-only, reporting-focused template: ideal for a first rollout into self-service because it can't misconfigure production systems.
  • Behind every tile is a standard job template with a scoped inventory, least-privilege credentials, and a survey — build these deliberately, since operators will never see the playbook path or extra vars directly.
  • Reserve destructive or configuration-changing templates (firewall remediation, patching, WiFi resets) for later rollout phases, layered with approval workflows once your team trusts the self-service pattern.
  • Treat any specific field names or API shapes for a newly announced feature as illustrative until Red Hat publishes full documentation — validate against your own access-control and logging integrations before production use.

Category: security-compliance

Browse all Ansible tutorials · AnsiblePilot Home