What a profile is, and why it comes first#
A deployment profile is the desired configuration a group of endpoints converges on. It answers four questions before any machine exists: how machines join, how much the agent may do unasked, what may leave a device, and which locations are pre-approved.
Configure the profile before you send a single invitation. Every enrolment binds a machine to a profile, and the profile is what the agent asks the control plane for on every reconcile. Getting it right first means you never have to explain to somebody why their laptop started indexing a folder overnight.
A workspace ships with a default
You will find one profile already there, marked DEFAULT. You can edit it or create your own. Every workspace needs at least one, and one profile must be the default. It is what an enrolment with no profile named falls back to.
Creating one#
Open Profiles
/console/profiles. The table shows every profile with its enrolment mode, autonomy ceiling, device-review setting, revision number, endpoint count, how many have not converged, and its gateway.
Press New deployment profile
Name it after the population it governs, not after the settings: Engineering laptops, Field tablets, Contractors. The name appears in enrolment invitations and on every device’s status output.
Work through sections 03 to 07 below
Each is one field on the editor. Two of them, autonomy ceiling and managed sources, change what happens on other people’s machines, and the console will ask you to write a reason before it lets you widen either.
Save, and read the diff
Before committing, the editor shows a before/after of every field you touched. Read it. A change that widens is highlighted with the consequence spelled out in operator terms: what actually starts happening on people’s machines.
Enrolment mode: how a machine joins#
- Managed
- An admin-managed corporate device. A redeemed enrolment becomes ACTIVE immediately, with no approval step. Use for machines you already control.
- Zero-touch (MDM)
- Pushed by device management with no interactive user present. Also auto-activates. Use with a fleet token and an image.
- User-assisted
- The employee signs in on the device, and the endpoint arrives PENDING, and an administrator must admit it from the Review queue’s Enrolments lane. Use when a person, not an image, is doing the install.
Auto-activate is a real decision
Managed and zero-touch admit a machine the moment a valid grant is redeemed. That is correct for hardware you own and wrong for a bring-your-own-device population, where the approval step is the only chance anybody has to notice an unexpected machine.
Autonomy ceiling: what the agent does unasked#
Three rungs, least autonomous first. This is a ceiling: the agent may do less, never more.
| Ceiling | What the agent does on its own |
|---|---|
| Manual | Nothing. The person starts every capture. |
| Continuous | Scans and enriches approved sources on its own, without anybody starting it. It prepares nothing for sync. |
| Prepare drafts | Also builds context-pack drafts on its own, from sources the person has already approved. Whether each pack then waits for that person is the device-review setting below. |
Auto-approval is not on this ladder at all. There is no setting on a deployment profile that lets a pack leave a device without either a person on that device or an administrator’s managed-source decision standing behind it.
Device review: the gate on the machine#
Three states, and the third is a real value rather than a missing one.
- Required
- Every context pack waits for the person at the device before it leaves.
- Not required
- Packs from this fleet sync with nobody on the device seeing them first.
- Inherited from workspace
- This profile states no opinion and takes the workspace ceiling. Not the same as copying the workspace’s current answer. If the workspace setting changes later, an inheriting profile follows it.
What turning device review off actually does
It does not mean content syncs unreviewed. It means the person whose machine it is no longer gets to decide what leaves it, and admin-managed folders are indexed and synced on the administrator’s decision alone. Every pack still lands in this workspace’s verification queue, and nothing is published without a steward approving it there.
Turning it back on is a narrowing: it applies on one click and never asks for a reason.
Managed sources: locations you pre-approve#
A profile can name locations from a fixed catalogue, so a device does not start with an empty list. Each one is added in one of two modes, and the difference is the whole ethical weight of this screen.
- Suggested
- The device offers the location to its owner and indexes it only if they agree. Appears on their device page as “Suggested · you agreed”.
- Managed
- The location is indexed without asking. The person is not consulted and cannot remove it themselves. Appears on their device page as “Added by your admin”, with the standing option to object.
The catalogue
- Local: Desktop, Documents, Downloads.
- Cloud (synced drives): OneDrive (Personal), OneDrive for Business, SharePoint synced libraries, Google Drive, Dropbox, iCloud Drive.
Preset keys resolve to device-local paths by the agent at reconcile time, so one profile works across macOS, Windows and Linux without you writing a path.
Adding a managed source is a widening
The editor names it explicitly, saying “these locations are indexed without asking”, lists which ones, and requires a written reason before it will commit. That reason goes on the audit trail beside the change. Prefer suggested unless you have a specific reason the person must not be asked.
A profile with no managed sources at all is a perfectly good default, and it is what a fresh workspace has: the console states it plainly: “no deployment profile pre-enables a location, so an invited person approves every source on their device before Evodira can index it”.
The rest of the form#
- Release channel
- Which agent release stream this fleet follows. stable by default. Chapter 14 covers rollouts.
- Policy refresh
- How often devices on this profile re-fetch policy. A device that cannot reach the plane keeps its last-good policy rather than falling open.
- Fog gateway
- The site-local relay this fleet prefers, if one is bound. Read-only here; gateways are registered in Fog gateways. With none bound, devices post context packs straight to the control plane, which is what every device in the field does today.
- Status
- ACTIVE or not. An inactive profile accepts no new enrolments.
Revisions and convergence#
Every saved change bumps the profile’s REV number. Devices converge on the new revision at their next reconcile, and the profiles table shows a NOT CONVERGED count: how many endpoints are still on an older revision.
- A non-zero not-converged count right after a save is normal. It should fall to zero within a policy-refresh interval.
- A count that stays non-zero means those machines are not talking to the control plane. Chapter 14 covers finding out which ones and why.
- not readable in that column means the convergence aggregate itself could not be read, not that the number is zero.
Profile changes apply to the next reconcile for existing endpoints. One thing does not: the control plane address a device talks to is decided at enrolment and applies to the next enrolment only. Endpoints already enrolled do not move.
You are done when
Profiles lists a profile named after a real population, with an enrolment mode that matches who owns those machines, an autonomy ceiling you can justify out loud, device review deliberately set, and every managed source either suggested or accompanied by a reason on the audit trail.
Something here wrong, missing, or no longer true of the product? Write to hello@evodira.com. Documentation that has drifted from the console is a bug and we treat it as one.