If you do not have GitHub org owner rights, you can still usually move forward by asking the right person for approval, then finishing setup with a small, scoped pilot. The goal is to get connected quickly without waiting on full admin access.
For DeliveryCompass, the shortest path is usually: confirm who can approve the GitHub App install owner permission, decide whether to use the read-only App install or OAuth path, and keep the first pilot limited to the teams and repos you actually need. This is engineering intelligence for GitHub PR delivery, so the setup starts narrow and stays focused on the GitHub PR metadata you need for review. If the setup needs to stay narrow, review the pilot limitations before you start.
What you can do without org owner access
Lack of org owner rights does not have to block you completely. In most teams, an engineering manager can still prepare the setup, define the scope, and hand off only the approval step to the right GitHub owner.
- Identify the GitHub organization owner or a person who can approve the App install.
- List the repos and teams you want in the first pilot.
- Confirm whether your org prefers the read-only GitHub App install or OAuth.
- Use the setup to focus on a single team before expanding.
That approach keeps the approval simple and avoids asking for more access than the pilot needs. If you want the full setup flow, start with the setup guide.
Pick the lightest approval path first
When access is the blocker, the right move is to choose the simplest path that still gives you useful delivery data. In practice, that means favoring a read-only install or OAuth flow that a GitHub owner can approve once, then letting the daily sync do the rest.
Before you ask for approval, check the install details and make sure you can explain what will be visible and what will not. The how it works page is useful for that conversation, and the FAQ can help answer common security questions from owners.
What to say to the org owner
Keep the request short and specific:
- We only need a read-only connection for delivery reporting.
- We want to start with one team and a small repo set.
- No broad rollout is needed yet.
- We can review the pilot before expanding access.
That makes the approval easier because the owner can see the scope and the intent right away.
Keep the first pilot narrow
If you cannot get broad access, do not force a broad setup. A narrow pilot is often the fastest way to prove value and earn wider approval later.
Start with one team, the repos they actively own, and the metrics you need for a weekly review. Then use the dashboard to look at trend charts, the team performance table, and drill-downs only for that group. If you want to map ownership cleanly, see teams and repos.
A narrow pilot also reduces setup back-and-forth. Instead of negotiating every repo in the org, you can point to one team’s workflow and expand from there.
Use team and repo mapping to avoid access sprawl
One common reason setup stalls is that people assume they need full org visibility before starting. In practice, scoped mapping is often enough to get a useful first read.
Map only the teams and repos you plan to review in the pilot. This helps you keep KPIs aligned to the right people and prevents confusion about what the dashboard is measuring. If you need a deeper reference, review the metrics guide and the dashboard overview.
Once the first team is mapped, you can compare patterns more safely and decide whether the next step should be another team or a broader rollout.
What to check before you ask for approval
A clean approval request usually answers the owner’s questions before they ask them. Use this checklist before you send the request:
- Which GitHub org needs to be connected?
- Which team is in scope for the pilot?
- Which repos are included?
- Will the connection be read-only?
- Who will review the pilot results?
If you are still deciding how to frame the pilot, the choosing delivery metrics page can help you pick a small set of metrics that fit a manager review without overreaching.
What happens after the connection is approved
Once the org owner approves the connection, the rest of setup should stay straightforward. After the read-only install or OAuth approval, the daily sync can start pulling in GitHub PR metadata, and you can begin reviewing team trends in the dashboard.
From there, many managers start with the weekly summary for staff meetings and then use team analytics when they want to drill into a specific pattern. If you want a quick overview of the weekly flow, see weekly summary. For deeper chart views, use team analytics and chart milestones.
If anything looks off during setup, the troubleshooting page is the place to check before widening the scope.
FAQ
Do I need org owner rights to start a pilot?
Not always. In many cases, you can prepare the scope and have an org owner approve the read-only install or OAuth step, then move ahead with a limited pilot.
Can I connect just one team first?
Yes. A single-team pilot is often the right way to reduce approval friction and keep the setup manageable.
Is a broad org-wide install required?
No. Start with the smallest useful scope, then expand only after the first pilot shows value.
What if the owner wants to know exactly what will be visible?
Point them to the setup and how-it-works docs, and be clear that the first pilot only includes the teams and repos you choose.
Where should I look if the approval is done but data does not appear?
Check troubleshooting first, then confirm the team and repo mapping in teams and repos.
If you want a guided start after approval, you can begin at /app/onboarding and set up the first scoped pilot in a few steps.