Outbound requests let HQ teams ask branches for information, photos, or other content -- all from one central place. Instead of chasing updates over email or chat, you send a structured request that branches can respond to directly within Rool.
The basic idea
Think of an outbound request as a to-do you assign to one or more branches. You describe what you need, pick which branches should respond, and optionally set a due date. Each branch then sees the request in their Received inbox and can reply with a message, upload files, or share links.
Here are a few common use cases:
Local photos -- "Please send updated storefront photos for the spring campaign."
Event information -- "Share your upcoming in-store event details for the regional calendar."
Promotions and inventory -- "Confirm which sale items you'll be stocking next month."
Feedback and surveys -- "Let us know how the new signage rollout went at your location."
How outbound requests differ from content requests
Rool has two types of requests, and they flow in opposite directions:
Outbound requests |
Content requests |
|
|---|---|---|
Direction |
HQ sends to branches |
Branches send to HQ |
Who creates it |
HQ admins and editors |
Branch managers |
Purpose |
HQ needs something from branches (photos, info, feedback) |
Branches need something from HQ (marketing assets, templates, copy) |
Where you find them |
HQ sees them under Sent; branches see them under Received |
Branches see them under Sent; HQ sees them under Received |
Both request types live side by side under the Requests section in the sidebar, organized into Sent and Received views so you always know what you have asked for and what others are asking of you.
Who can do what
Your role determines how you interact with outbound requests:
HQ users (admin or editor) can create outbound requests, view all responses, mark a branch's response as fulfilled, and re-request if a branch declines.
Branch managers receive outbound requests for the branches they manage. They can respond with a message, file uploads, or links -- or decline the request with a reason.
Lifecycle of an outbound request
Each branch that receives a request goes through its own status cycle:
Pending -- The request has been sent but the branch has not yet responded.
Responded -- The branch has submitted at least one response (message, files, or links).
Fulfilled -- An HQ user reviewed the response and marked it as complete.
Declined -- The branch indicated they cannot fulfill the request and provided a reason. HQ can choose to re-request, which resets that branch back to Pending.
Because the request is sent to branches individually, each branch moves through the lifecycle independently. One branch might already be fulfilled while another is still pending.
Where to find outbound requests
Sent -- Open the Requests section in the sidebar and click Sent. This shows all requests you have created, including outbound requests sent to branches and (if applicable) content requests you have submitted to HQ. You can filter by status, priority, or type.
Received -- Click Received under the same section. Branch managers see outbound requests assigned to their branches here. HQ users see content requests submitted by branches.
A badge on the Received item in the sidebar lets you know when new requests are waiting for your attention.
What happens when you create a request
When an HQ user sends an outbound request, each selected branch is notified automatically:
An in-app notification appears for the branch's managers.
An email notification is sent (based on each user's notification preferences).
Automatic reminders can be enabled to nudge branches about requests that are still pending.
Likewise, when a branch responds or declines, HQ users are notified so they can review the submission promptly.
Next steps
Ready to create your first outbound request? See the next article for a step-by-step walkthrough of creating, sending, and tracking an outbound request.