Operators
Link resources
Resources are the groups, channels, teams, drives, and calendars Camper keeps aligned with your org chart. Operators link them under Resources → Link resources.
Prerequisites
- At least one imported org unit in the catalog
- An active connection for the app you want to use
- Owner or admin role
Summary of steps
- Choose what to link — create something new, or pick objects that already exist
- Set the rules once — who gets access, lifecycle, naming
- Review the dry run and confirm
Linking resources
Resources → Link resources opens a panel with three panes.
1 · Choose
Start with what you are actually doing:
| Intent | What happens |
|---|---|
| Create new | Camper creates the object in the app and owns its lifecycle. Only types Camper can create appear — private channels and SharePoint sites are not among them |
| Link existing | Camper manages membership on objects that are already there. This is the common case |
Pick the app on the left, then what to link on the right. In Link existing that is one searchable list per app: close name matches for the unit first, then everything else. Tick as many as you like — one object or twenty costs the same clicks, and your selection survives switching apps, so a Google group and a Slack channel can go in one batch.
Resource type is not a step. When linking, it comes from the object you tick. When creating, it is two to four cards.
Find matches across apps scans every connected app for objects whose names resemble the unit and shows a count beside each app. Nothing scans until you ask — no page fires live provider calls on load.
Objects Camper already manages are shown as already linked and cannot be ticked twice. If a list is capped or an object cannot be listed (Google calendars, private Slack channels without the bot), paste its id.
If Camper cannot read an app, the results pane shows a short error, a Reconnect link to Connections, and Show details for the raw provider message. The list stays empty rather than filling with token-exchange text.
Starting from an org unit
An imported unit's page has Link resources, which opens the same panel with that unit already fixed.
2 · Rules
One set of rules for everything in the batch. They start from your workspace defaults, and the banner links straight to them.
3 · Review
The dry run, for one object or twenty. See Dry-run before go-live.
Editing an existing link
Open the resource → Edit rules on the org unit you want to change. It is the same panel with the first pane collapsed: the connected app and resource type are fixed once a link exists, so only the rules and the org unit remain.
Review changes shows the dry-run diff, then Save & apply. The worker applies membership on the next reconcile.
To move a resource to a different app, unlink it and link it again.
One resource, several org units
A resource can follow more than one unit — a channel shared by two teams, for example. The resource page lists every linked unit with its own rules, and Link another unit adds one.
Where two links disagree, the lenient rule wins: any add-only link makes the resource add-only, and any link that keeps leavers keeps them. Only one link may drive naming; the resource page names which.
Unlink drops one unit without deleting the resource. People already in it keep their access — unlinking never empties a resource. With no links left, Camper simply stops aligning membership.
Managed vs attached
| Mode | What Camper owns |
|---|---|
| Create new (managed) | Creates the object (when supported), can follow org naming, and drives membership |
| Attach existing | Membership on an object that already exists. Can still follow org naming and be renamed from Camper |
Create waits for the app
When you Confirm & go live on a managed create, Camper calls the connected app before saving the resource. The UI stays on a loading state until the object exists downstream.
- Success — Camper stores the resource with its external id and enqueues membership reconcile.
- Failure — nothing is saved in Camper; you see the error and can fix credentials/settings and retry.
That avoids orphan Camper resources that never existed in the app.
Delete a resource
On the resource detail page, Delete (owners and admins):
| Choice | Effect |
|---|---|
| Remove from Camper only | Drops the Camper resource, link, and memberships. The app object stays. |
| Also delete in the app | Deletes (or archives) the object in Google / Atlassian / … when the connector supports it, then removes Camper rows. You must type the resource name to confirm. |
If downstream delete fails, Camper does not remove its record — fix the connection and retry, or choose Camper-only.
When attaching, Camper can browse and search live resources. Paste an id if listing is incomplete.
Google Shared Calendars — Google has no domain-wide shared-calendar directory. Browse shows secondary calendars on the connecting admin’s list only. See Google Workspace.
Google Shared Drives — domain-wide when that admin has Manage shared drives; otherwise only drives they belong to.
Slack private channels — the Camper bot must be invited into the channel before Camper can list it in resource search, read membership, or change who is in it. Public channels do not need a manual invite (Camper joins on first write). See Slack → Private channels.
Naming
Naming is one question with two answers, asked on the Rules pane. A preview box shows the name the resource will actually carry, including what happens the next time the org unit is renamed.
| Choice | Then | What it means |
|---|---|---|
| Automatic | Use the <app> template | The name renders from that app's naming template and keeps matching the unit |
| Custom template | Same, with a template for this link only | |
| Manual | Keep <current name> | Camper never renames it, whatever happens to the unit |
| Change it now | Renamed once in the app when you confirm, then never again |
Rename on the resource page still changes the name in the app immediately.
Naming templates, per app
A single template cannot serve every provider: a name that reads well as a Google Group is illegal as a Slack channel. Templates therefore live under Settings → Resources, one per resource type on each connected app.
| App | Type | Template | Result |
|---|---|---|---|
| Google Workspace | Group | {{org_unit.name}} {{org_unit.kind}} | Platform Engineering Department |
| Slack | Channel | #{{org_unit.name}}-team | #platform-engineering-team |
| Slack | User group handle | {{org_unit.abbrev}}-{{org_unit.name}} | @dept-platform-engineering |
Each row previews the rendered name with that provider's own rules applied (Slack lowercases and hyphenates, and so on). A type with no template of its own uses the workspace default, so nothing changes until you set one.
Some types have a second identifier besides the display name. Set that on the same card:
| Type | Identifier | Typical template |
|---|---|---|
| Slack user group | Handle (@…) | {{org_unit.abbrev}}-{{org_unit.name}} so #marketing and @dept-marketing do not collide |
| Google Group | Email local-part | Same idea — display name can be “Marketing Department” while the address is dept-marketing@… |
Leave the identifier empty to derive it from the display name, as before.
Available tokens:
| Token | Renders |
|---|---|
{{org_unit.name}} | The unit's display name |
{{org_unit.kind}} | Its kind — Department, Team, … — or its axis slug |
{{org_unit.axis}} | The axis display name |
{{org_unit.parent}} | The parent unit's name, empty at the root |
{{org_unit.abbrev}} | Short form of the kind or axis — dept, div, team. Set this on the axis under Settings → Mappings, or per level when the axis uses nested levels |
A template needs at least one token; without one it could never follow a rename, so Camper asks you to use Manual naming instead.
A resource linked to more than one org unit uses one naming template. If two links would produce different names, Camper does not auto-rename — pick a single driver on Edit rules.
SharePoint sites cannot be renamed from Camper.
When the directory renames a unit first
Department-style attributes have no stable id in the IdP. If HRIS renames “Shared Services” to “Corporate” before Camper, people look like they moved to a new unit and linked channels stay on the empty one.
- Prefer Catalog → Rename on the unit before or as the IdP catches up, so matching stays on the same row.
- If the sibling already exists, open the empty unit (or the catalog banner) and Treat as rename. That moves links onto the surviving unit; follow-naming then updates downstream names. If people really moved, choose Not a rename so the banner goes away.
IdP groups (the Teams axis) already rename in place — Camper keys those units on the group id.
Workspace defaults
Owners and admins set defaults for new links under Settings → Resources:
| Default | What it does |
|---|---|
| Naming | Whether new links default to automatic naming, and the fallback template for any app with no template of its own |
| App naming templates | Per-type overrides on each connected app (Slack channel vs Google Group). Empty rows use the workspace template |
| Description | Optional text stamped onto new managed app objects (Google Groups, Slack usergroups/channels, Microsoft teams/groups, GitHub teams, Atlassian teams) when the provider supports a description |
| Access defaults | Pre-fills who gets in, role, and the three lifecycle answers on the Rules pane |
Defaults apply only when linking a new resource. Operators can still change every field on that link. Changing defaults does not rewrite existing resources or links.
The same page lists Exempt accounts — standing members Camper never adds, removes, or reports. See Exempt accounts.
Access rules
The Rules pane opens with a sentence carrying the two link-specific decisions:
Add everyone in Design to #design-team as a member.
| Control | Options |
|---|---|
| Who gets access | everyone in <unit> (that unit only) or everyone in <unit> and below (every nested unit, now and in future). Shared Drives and Calendars add a third option — see group-delegated access |
| Access level | member for ordinary unit members. Prefer not using owner for day-to-day links. For higher access, set org unit leads (Google Group Manager, Shared Drive Content manager). Slack and Atlassian teams have no elevated membership role. |
Lifecycle
Three questions, asked plainly. Joiners are always added; these decide what happens afterwards.
| Question | Options | Default |
|---|---|---|
| When someone moves out of the unit | Remove / Keep | Remove |
| When someone leaves the company | Remove / Keep | Remove |
| When people appear that Camper didn't add | Audit / Remove / Ignore | Audit |
What these do on that pane opens the full explanation with worked examples. In short:
- Moves out — Keep is add-only: Camper keeps adding joiners but never removes a mover. Use it for channels people stay in after a reorg.
- Leaves the company — Remove covers apps your IdP does not reach. Most IdPs already pull leavers out of SCIM-enabled apps; Google Groups is the common gap, where teams often need a custom offboarding workflow.
- Camper didn't add — Audit lists them as drift on Activity, where you keep or remove each one by hand. Camper never removes them on its own. Remove is the setting that enforces membership automatically — use it on resources that must match the org chart exactly.
Two guarantees hold whatever you choose: people with no matching Camper identity are never removed, and exempt accounts are never added, removed, or reported.
Earlier versions offered Full sync / Add-only / Custom presets. They are gone: "Full sync" left the outsider rule on audit, so it synced only the members Camper had placed while its name implied it enforced the whole roster.
Add-only and retained members
- Retained members are Camper-placed people still present but no longer desired. They are not external drift.
- Resource detail lists them under Retained by policy.
- Dry-run Review shows a Retained count before you confirm.
Group-delegated access
Google Shared Drives and Shared Calendars can hand membership to a Google Group instead of listing people. Pick the Google Group for <unit> in the sentence and Camper grants the Google Group linked to the same org unit as a single ACL principal; Google expands who is inside it.
Because Camper no longer places individuals on that drive or calendar, the movers and leavers rules do not apply — those are the group's business, and the Lifecycle section reduces to one rule:
| People granted access directly | Meaning |
|---|---|
| Report (default) | Anyone holding a direct ACL outside the linked group is listed as drift on the resource. Camper changes nothing |
| Remove | Camper removes direct ACLs so the linked group is the only way in. People inside the group keep their access |
Link a Google Group resource to the same org unit first — without one there is nothing to grant. See Google Workspace.
Slack default channels
A Slack channel can also be a default destination for a Slack user group, independently of the org-unit link. Current and future members of the group are added to the channel; leaving the group does not remove them.
Set this on the channel or user group resource (Default for user groups / Default channels), or in Slack with /link-channel @group. The Camper bot must already be in a private channel. See Slack.
Dry-run before go-live
Every link and every edit ends on Review — for one object or twenty. Camper computes desired membership and, when a downstream id exists, reads live membership from the app. People already in the channel or group show as already in, not as Add. Confirming updates the link; the worker applies membership ops on the next reconcile.
The batch total reads as a sentence, and every row expands to its own full membership plan. Rows settle independently: if one app rejects a create, that row fails and the rest still land, with the failures left on screen.
If a resource cannot be read live — a private Slack channel without the Camper bot, say — the row is flagged and the plan falls back to last-known membership.
Pin from Review
Someone already on the resource who is not in the linked org unit shows as Will remove. If they should stay (a contractor, an EBP, a legacy owner), click Pin on that row before you confirm:
- The plan updates immediately — they move to Pinned and are no longer removed
- Go-live / Save writes the pin with the link; the worker keeps them on the next reconcile
- Unpin on Review undoes a pin you just added; existing pins stay managed on the resource page
You can still pin people later from the resource detail page (search or pin an expected member).
Membership exceptions (pins)
Some people must stay on a resource without belonging to the linked org unit — for example an Executive Business Partner on a C-suite channel.
From Review (link create / edit): Pin on a Will remove row so they are not removed when the link goes live.
From the resource detail page:
- Pin a person (search the directory) or Pin on someone already under Expected members
- Pinned members are always desired while they are active, independent of org placement
- They show a pinned badge under Pinned exceptions
- Unpin clears the exception; the next reconcile removes them if they are not org-desired
- Leaving the company still wins — suspended or deprovisioned people are not desired even if pinned
Do not turn off sync for the whole resource to keep one-offs — use pins.
Exempt accounts (workspace admins and bots)
A required admin such as it.admin@company.com on every Google Group or Shared Drive is not a pin. Pins keep someone desired. That admin should stay where they already are and never be added elsewhere.
Add the email under Settings → Resources → Exempt accounts. Camper then:
- Does not add them when they sit in a linked org unit
- Does not remove them, even if the link enforces outsiders
- Does not report them as drift
Dry-run Review lists them under Exempt accounts. Guide: Exempt accounts.