Badger Data Access: Approvers - Taking Action on a Request
The Badger Data Access application is designed to automatically route requests from users to the appropriate Supervisor, Divisional Approver (if applicable), and Domain Steward. A role request must pass all levels of approval before access will be provisioned to the user.
Approvers may take any of the following actions on a request:
-
- Approve – Approve the request and advance it to the next step in the workflow approval process.
- Deny – Deny the request and terminate the workflow.
- Pushback – Send the request backwards in the workflow to the user for updates. Only the Justification, Classification Level, Row Level, and/or Expiration Date may be adjusted.
- Supervisor or Divisional approver: - If a workflow is pushed back by the Supervisor or Divisional Approver, upon resubmission by the user the approval chain will restart with the Supervisor.
- Domain Steward: If a workflow is pushed back by the Domain Steward, upon resubmission by the user the request will skip previously completed approval steps and route directly back to the Domain Steward that issued the pushback.
A comment is required when denying or pushing back the workflow for a request. Each level of approval has visibility into the comments entered by any approvers before them in the approval workflow.
To act on a request:
- Click the link in the email notification received or visit access.data.wisc.edu to login.
- On the Approval Details page, review the request details outlined below.

-
-
- The Request ID and requestor information is displayed at the top of the page
- Review the Justification entered by the requestor
- Review all roles listed in the request
- Supervisors and Divisional Approvers may click the More Info button on a corresponding row to view the Role Request ID, Domain/Subdomain and Requested Classification & Row Level. If the user already possesses the role but is requesting a change to their current classification or row level, the user’s current access displays under Existing Role

NOTE: Domain Stewards will see a summary of the Requested Role routed to them directly on the page under the Approval Details section
- Review the Workflow history of the request at the bottom of the Request Details screen

*IMPORTANT NOTE: The action taken on a request will apply to all roles contained within it. - Approve, Deny, or Pushback the request for changes.
- To Approve the request:
- Select the Approve radio button
- Enter a comment if desired (optional for Approve actions)
- Click Submit
- To Deny the request:
- Select the Deny radio button
- Enter a comment to the user explaining the reason for denial (required)
- Click Submit
- To Pushback the request workflow:
- Select the Pushback radio button
- Enter a comment explaining the reason for Pushback (required) including what updates or clarification is being requested. If the request includes multiple roles, be sure to specify which Subdomains may need adjustments.
- Click Submit
- To Approve the request:
-
Approved requests are routed to the next approver in the workflow or provisioned by hourly sync to Manifest once all approvals have passed. The user is notified via email once a request is granted.
Denied requests terminate the workflow. The user is notified via email when a request is denied. The user may submit a new request if necessary.
Requests that are pushed back by the Supervisor or Divisional approver are returned to the user for updates. The user is notified via email that their request has been Pushed Back. Once they make the necessary updates and resubmit, the approval workflow starts over again with the Supervisor.
Requests that are Pushed Back by the Domain Steward are returned to the user for updates. The user is notified via email that their request has been pushed back to them for additional information. Once they make the necessary updates and resubmit, the request is routed directly back to the Domain Steward that issued the pushback, without the need for re-approval by the Supervisor and Divisional approver (if applicable).