SaaS administration

Check new-hire access prerequisites before provisioning begins

Build a dependency-first readiness record so new starters receive approved access without rushed guesses or duplicate accounts.

A start date is not enough information to provision a new employee. The useful question is whether every dependency for safe access is ready: an approved worker record, a responsible manager, a defined role, a supported device, a verified identity route, application owners, and a clear first-day business need. Treating the request as one large checklist hides sequencing. An email account may depend on the authoritative name and employment state. A project tool may depend on the email address. A privileged console may require training, manager approval, and a managed device. A readiness record makes those relationships visible before an administrator creates anything.

Begin with the authoritative people record and the approved request channel. Capture the worker identifier, preferred display name, legal or payroll name only where a system truly needs it, employment or contractor status, manager, sponsor for external workers, start time with time zone, expected end date when applicable, and the person who approved the role. Do not copy a spreadsheet row into every application as if it were permanent truth. Record the source and observation time. If the manager, start date, or worker type conflicts across systems, pause the affected branch and ask the people-operations owner to resolve it. The assistant can coordinate that question but should not decide which record wins.

Next, translate the role into outcomes rather than cloning another employee. A useful access request says that the new support coordinator must receive customer tickets, update approved knowledge articles, join the support schedule, and view a specific reporting dashboard. It does not simply say give Alex the same access as Morgan. Role copying carries historical exceptions, temporary groups, regional data, and privileges that may not belong to the new starter. Ask each application owner for the smallest role that supports the named work. Keep standard access, optional access, privileged access, and exception requests separate so one unresolved item does not obscure the rest of the first-day plan.

Build a dependency map for every requested service. Identify the system owner, approval evidence, prerequisite identity, license availability, authentication method, device requirement, data boundary, provisioning mechanism, expected completion signal, and fallback contact. For example, a password-manager invitation may require the corporate mailbox, but shared-vault membership should wait for the vault owner. A code repository may require single sign-on plus an approved team. A phone platform may require a number, emergency-location information, and a telecom owner. When a dependency is missing, record blocked by and the owner of the next decision instead of marking the entire onboarding request late.

Use time deliberately. Some accounts can be staged before the worker arrives, while others should not become usable until the approved start. Write down whether creation, license assignment, group membership, credential delivery, and activation happen together or at different times. Never send passwords through an ordinary ticket or personal email. Prefer the organization’s approved enrollment and recovery process. NIST Digital Identity Guidelines at https://pages.nist.gov/800-63-4/ provide current primary guidance on identity proofing, authentication, and authenticator management. They do not prescribe the company’s local role approvals, so keep policy decisions with the identity and security owners.

Test the plan against an ordinary case and an exception. Imagine a remote contractor whose laptop shipment is delayed. The collaboration owner may approve browser access to low-risk tools from a supported device, while the security owner may prohibit access to customer data until the managed laptop arrives. The readiness record should show those as separate decisions, each with scope and expiry. It should not quietly replace the device requirement with a personal-device assumption. Another common exception is a changed start date after accounts were staged. The coordinator should identify what is already created, prevent premature activation through the approved process, and obtain fresh timing from the authoritative owner.

Provisioning evidence must be specific. An administrator saying done does not show which identity, tenant, role, or group changed. For each action, retain the stable account identifier, target service, assigned role or entitlement, implementer, approved request, completion time, and any warning returned by the platform. Do not store tokens, recovery codes, private messages, or screenshots containing unrelated users. Microsoft’s identity documentation at https://learn.microsoft.com/en-us/entra/identity/ and Google Workspace administrator documentation at https://support.google.com/a/ describe their respective platform behavior. Use the documentation for the configured platform rather than assuming that group propagation or invitation status works the same everywhere.

First-day validation should follow the employee’s real work path without turning the employee into a tester for every integration. Confirm that the person can complete approved sign-in, register an allowed authentication method, reach the correct service, and perform a harmless role-appropriate action. Check that expected restrictions also hold. A successful login does not prove the worker received the right data scope, and membership shown in an admin console does not prove a dependent application has synchronized. Record expected and observed results separately, including propagation delays and the owner of unresolved behavior.

Security and privacy stop conditions belong in the workflow. Escalate identity mismatch, an unexpected privileged role, a request to bypass multifactor authentication, a personal email used for corporate recovery, unknown sponsorship, access to sensitive records without a data owner, or pressure to share credentials. CISA’s Cybersecurity Performance Goals at https://www.cisa.gov/cybersecurity-performance-goals offer practical identity and access-control priorities. They are a baseline, not evidence that a particular local configuration is safe. The security owner decides exceptions and compensating controls; an IT virtual assistant maintains the evidence and follow-up queue.

Close readiness by reconciling the intended access list with fresh observations after the start. Mark each item ready, intentionally deferred, rejected, expired, or unresolved. Confirm ownership of temporary exceptions and assign their review dates. Remove duplicate invitations and abandoned staged accounts through the authorized administrator process. Report useful measures such as requests missing a manager, dependencies discovered after provisioning, privileged requests lacking a separate approval, time from prerequisite completion to usable access, and exceptions still open after their expiry. Avoid a simple percentage that rewards creating accounts quickly while hiding incorrect access.

A good joiner workflow gives the new employee a calm first day and gives system owners a defensible record of why access exists. It does not promise zero delays; it exposes dependencies early enough for the right owner to act. ITVirtualAssistant can help small teams maintain intake records, chase approvals, reconcile completion evidence, and document unresolved dependencies while administrators retain control of identities and permissions. Review the relevant support options at /services if recurring onboarding coordination is consuming technical time.

How to use this guide

Use this page to decide what an IT virtual assistant should handle first. If the task is recurring, documented, and easy to review, it is usually a better first delegation candidate than work that requires live technical judgment.

Treat the article as an operating brief, not just a topic overview. The goal is to turn loose IT work into a named workflow with inputs, outputs, permissions, review cadence, and a handoff rule that protects the business while reducing manager load.

Decision rules

Delegation checklist

• Write the intake source, expected output, and manager review cadence.
• Confirm the assistant has only the permissions needed for the workflow.
• List the events that require escalation before work continues.
• Track examples for two weeks before changing the workflow.
• Save examples of good and bad outputs so the assistant has concrete references.
• Review the workflow monthly and remove permissions that are no longer needed.

Example first-week agenda

Day one should cover the workflow owner, tools, allowed actions, forbidden actions, and escalation language. By the end of week one, the assistant should have produced a small sample of completed work, a list of unclear requests, and a manager-reviewed improvement note.

What to review before delegating

Confirm the owner, access level, review cadence, and escalation path before assigning any recurring IT workflow to a remote assistant.

What should an IT virtual assistant handle first?

Start with repeatable, reviewable work such as ticket summaries, account records, documentation updates, and checklist follow up.