If you have ever set up a new tool inside Canvas and watched it fail to recognize a single one of your students, you already understand why user synchronization matters. The integration looked installed. The button appeared. But when a student clicked submit, the system had no idea who they were. That gap, between "the app is connected" and "the app knows who everyone is," is exactly what user synchronization closes.
This guide explains what user synchronization in Canvas actually is, how it works behind the scenes, and how to turn it on so that rosters, roles, and submissions move cleanly between Canvas and an external tool like Checkmark. It is written for the person who has to make it work, not the person who designed the spec.
What user synchronization actually means
User synchronization is the process of keeping the list of people in your Canvas course, and the role each person holds, accurate inside a connected external application. When it is enabled, the external tool knows that Ms. Alvarez is the teacher, that there are twenty seven students enrolled, and that a student who dropped the course last week should no longer appear.
It is worth separating two ideas that often get blurred together. Authentication answers the question "is this person allowed in?" Synchronization answers the question "who are all the people, and what is each one's job?" You can have one without the other. A student might be able to log in through Canvas yet still show up as an anonymous, unmatched account because the roster was never shared. Synchronization is what attaches a real identity, a real role, and a real course context to every click.
In practice, synchronization carries three things across the connection:
- Identity: each person's name and a stable identifier, so the same student is recognized session after session.
- Role: whether the person is an instructor, a teaching assistant, or a student, which determines what they can see and do.
- Enrollment: which course or section a person belongs to, so submissions land in the right place.
How it works under the hood
Canvas talks to external tools using a standard called LTI, which stands for Learning Tools Interoperability. Modern integrations use LTI 1.3 together with a companion specification called Names and Role Provisioning Services, usually shortened to NRPS. You do not need to memorize the acronyms, but it helps to know they exist, because the toggle you are looking for is often labeled with some version of "allow this tool to retrieve the course roster."
Here is the sequence in plain terms. When you add an external tool, you install it using a client ID and a deployment that an administrator registers in Canvas. From that point on, every time a user launches the tool, Canvas sends a secure, signed message that includes who the person is and what role they hold for that specific launch. That covers the individual.
The roster is a separate step. NRPS lets the tool ask Canvas, on its own schedule, "give me the full membership list for this course." Canvas responds with everyone enrolled, their roles, and their status. This is the piece that fills in students who have not launched the tool yet, and it is the piece that goes quiet if the relevant permission is switched off. So when people say synchronization is broken, what is usually broken is the roster call, not the individual launch.
Two consequences follow from this design. First, synchronization is not always instant. Depending on configuration, the roster can refresh on launch, on a timer, or when an admin triggers it, so a student added five minutes ago may not appear for a short while. Second, the permission to read membership is granted deliberately. Canvas does not hand over a roster to every tool by default, which is the right call for privacy but the exact reason setup requires a conscious step.
Setting it up, step by step
The precise menu names shift between Canvas releases, but the shape of the process is stable. You will move from the administrator level down to the course level.
1. Confirm you have the right access. Roster-level synchronization is configured by a Canvas administrator, not by an individual teacher. If you are a classroom teacher, your job is usually to confirm the tool is installed and then verify your roster appears. The steps below assume admin access for the configuration parts.
2. Install or locate the tool. In the Admin area, open Settings, then the Apps or Integrations tab. If the tool is already present, open its configuration. If not, add it using the LTI 1.3 client ID your vendor provides. Choose the developer key or client ID method rather than pasting an older XML configuration, because the older method generally cannot read rosters at all.
3. Approve the developer key and its scopes. Under Developer Keys, find the key for the tool and make sure it is set to On. Open its details and confirm the scopes include the membership and roster services. The scope you care about is the Names and Role Provisioning one. If that scope is missing, no toggle anywhere else will produce a roster.
4. Set the deployment to the right level. Decide whether the tool should be available account wide or only for specific sub accounts and courses. Account level deployment means every course inherits the integration, which is usually what schools want for a plagiarism and AI writing checker so that no teacher has to configure anything.
5. Enable roster retrieval. In the tool's placement or configuration settings, turn on the option that allows it to access membership or sync enrollments. This is the literal "user synchronization" switch. Save.
6. Verify at the course level. Open a real course, launch the tool as an instructor, and check that your student list appears and that roles look correct. The fastest sanity check is counting: does the number the tool reports match your actual enrollment?
A concrete example
Picture a high school rolling out Checkmark across its English department. The Canvas admin registers the LTI 1.3 key, enables the NRPS scope, and deploys the tool at the account level so all twelve English sections inherit it at once. A teacher in one section opens Checkmark, sees all twenty four of her students listed with the correct roles, and assigns a personal narrative essay. When a student submits, the originality and AI writing report attaches to that student's name automatically, because synchronization already taught the system who that student is.
Now contrast that with a half configured rollout where the scope was never approved. The same teacher opens the tool and sees an empty roster. Students can technically launch it, but their submissions arrive as unlinked, anonymous entries that someone has to reconcile by hand. Same tool, same teacher, completely different experience, and the only difference is one permission.
Common misconceptions and quick fixes
"The tool is installed, so synchronization is on." Installation and roster access are two different switches. A tool can launch perfectly while reading no roster at all. If your list is empty, check the developer key scopes first.
"Every teacher has to set this up individually." For most schools the opposite is true and far better. Configure synchronization once at the account level and every course inherits it. Per course setup should be the exception, not the plan.
"Synchronization updates instantly." Often it does not. Rosters may refresh on launch or on a schedule. If a newly enrolled student is missing, relaunch the tool or wait for the next sync before assuming something is broken.
"If a student can log in, they are synchronized." Logging in proves authentication worked. It says nothing about whether the course roster was shared. The membership call is separate, and it is the one that populates your class list.
"Turning on synchronization exposes more data than it should." A properly scoped LTI 1.3 integration shares names, roles, and enrollment, the minimum needed to match submissions to students. It is worth confirming with your vendor exactly what is requested, but reading a roster is a routine, privacy conscious part of how these tools work.
A short troubleshooting checklist
When the roster will not appear, work down this list in order, because it moves from the most common cause to the least:
- Is the developer key turned On and does it include the membership scope?
- Was the tool installed using the client ID method rather than legacy XML?
- Is the deployment scoped to include the course you are testing?
- Did you relaunch the tool after saving, to trigger a fresh sync?
- Does the reported student count match the real enrollment?
Get user synchronization right once at the top, and the rest of the year mostly takes care of itself: every student is recognized, every submission lands where it should, and nobody spends their planning period matching essays to names by hand.