Account Creation Is Where Trust Starts

When someone starts working in our district, I want them to have what they need to get started. Depending on their role, that might include email, a network login, multifactor authentication, a phone, and access to the student information system and other applications. A lot has to happen behind the scenes to make that first day go well.

If we ask people to enter the same information into several systems, we also create several opportunities to get it wrong. A wrong school, an outdated job title, or a typo can follow someone into their accounts and affect what they can access. An account can work and still give someone the wrong permissions.

We need the same care when someone leaves. If removing access depends on a series of manual steps, an account can remain active after employment ends. Our team needs a reliable way to handle both ends of that process.

That is why we are changing how we create and suspend staff accounts at Vail School District. We are moving that repeatable work out of individual Help Desk tickets and into an identity platform connected to our employee records.

Start with a record we can trust

We are working toward a practical set of goals: a trustworthy employee record, multifactor authentication on sensitive access, permissions that follow a person’s role, and timely removal of access when someone leaves. There is still work to do, and I would not describe this as a complete zero-trust architecture.

Our ERP is the source of truth for who is employed. From that record, the account process needs to put MFA in front of primary accounts and give people the access their roles require. That should be defined in the system, so our team does not have to remember how the last person in a similar role was set up.

On Wi-Fi, we have already moved from usernames and passwords to machine and profile-based authentication. The device and its managed profile establish that it belongs on the network. That removes the need for a Wi-Fi password that someone could share or give away through phishing.

Where we are starting

Our current process brings information through several systems:

1. A new hire is entered in our HR onboarding system.
2. Someone verifies that record and enters it into the ERP.
3. Primary accounts are created from there, some of them by hand.
4. Other applications pick up that identity in different ways, and many depend on role.

People are doing the work needed to connect those steps. I want the system to take on more of that repetition so our team can spend its attention on the information and decisions that need review.

The change we are making now

We are putting an identity platform between the ERP and the primary accounts. New hires will still enter through HR, and a person will still verify the employee record. The workflow we are implementing looks like this:

1. A new hire is entered in our HR onboarding system.
2. One person verifies the record in the ERP.
3. The identity platform creates employee portal, email, and network accounts from that record, with MFA in the path.
4. Apps grant access by role.

When the employee record shows that someone has left, that same process will suspend their accounts. Creating access and removing it need to be equally dependable.

This takes work beyond configuring an individual account. We have to connect the systems, agree on what each role needs, and decide how changes should move between them. Doing that work now gives our team a more consistent process to use day to day.

What stays human

People still need to verify employee information and decide what a role such as “teacher at this school” means in each application. Contractors, exceptions, and mid-year role changes need clear ownership too.

Our team also needs to make deliberate decisions about single sign-on, group design, and adding new applications. Those choices affect everyone who uses the system. Automating account creation gives us a reason to make those responsibilities clearer, and it does not remove the need for people to exercise judgment.

How we will know it is working

We will look for a few practical signs that the change is helping:

• New staff have working accounts on their first day.
• Staff accounts match active employee records, with contractors and other exceptions accounted for.
• The time from a separation in the employee record to suspended access keeps shrinking.

I want new staff to have what they need when they arrive, and I want our team to be confident that access is removed when someone leaves. Following an employee record through that whole process has helped make the work clearer: where it becomes an account, which steps need a person, and what happens on the last day. Those are useful questions to work through before choosing how to automate it.