A new employee's first day depends on several systems working together: an authorised role, an identity, the right device, appropriate applications and a support route available when something fails. A completed onboarding form does not prove that all those parts work. Small UK managed service providers often coordinate HR, managers, purchasing, cloud administrators and external software vendors on behalf of clients. Their job is to convert a confirmed starter request into a tested, accountable handover without granting permissions that nobody approved.
The most useful readiness plan separates four states: requested, approved, technically provisioned and verified by the actual user. This distinction prevents a workflow success notification from being mistaken for business authorisation or a functioning laptop. A starter may have an active cloud identity but no licence for the software needed to work. Another may receive equipment while remote sign-in is blocked by enrolment requirements. Neither is ready simply because an IT checklist was closed.
Start with one authorised request and a named owner
The client's manager or HR representative should provide the confirmed start date, appropriate time zone, role, location, sponsor and the business tasks the new colleague will perform. Different departments may describe the same role differently, so obtain specific requirements rather than inferring access from a job title. Record the authorised approver and where later changes must be submitted. A technician who notices an incomplete approval should not silently duplicate another worker's permissions to meet a deadline.
Identify equipment, accessibility and working-location needs through confidential, proportionate channels. A remote employee may require secure delivery, a first-login procedure and a support number that works before corporate applications are accessible. A contractor may need a defined expiry and client sponsor from the start. Keep sensitive employment details out of general support tickets; the IT request normally needs the identity, timing, entitlement decision and practical logistics, not a private personnel history.
Make the commercial boundary visible. An extra licence, specialist workstation or courier charge may need separate purchase approval. Record who will make that decision and when it affects the handover. A task should remain awaiting approval rather than changing into a fictional ready state. A single named coordinator can track these dependencies even where the actual provisioning work belongs to several specialists or suppliers.
Convert the working role into approved least-privilege access
List the tasks a starter genuinely needs to perform, then map those tasks to authorised applications, information resources and group membership. A finance worker might require a ledger and approved reporting access; a customer support worker might need the ticket queue and a limited customer record view. Those are illustrations, not universal role templates. Permissions require the business owner's current decision. Historical group membership can accumulate privileges that are no longer justified.
Check effective access, not merely the assigned group label. A user may belong to nested groups, have a shared mailbox delegation or receive separate rights through a vendor application. Distinguish ordinary accounts from privileged administrative identities. A senior manager is not automatically entitled to administrator functions. For especially sensitive resources, record any additional approver and exception review. The UK NCSC's introduction to identity and access management provides the relevant principles of identity, permission lifecycle and least privilege.
Account for external applications that are not managed by the main directory. A sign-in to Microsoft Entra does not prove a separate payroll, supplier portal or specialist programme has been provisioned. Keep a register of the receiving system, expected permission, technical owner and verification result. If access is pending, inform the manager of the actual consequence for the employee's work rather than asserting that the entire role is ready.
Provision identity, credentials and security controls safely
Create the correct identity through the organisation's approved process, with verified naming, authorised aliases and an appropriate authentication method. Set up multifactor authentication and legitimate recovery routes without asking an employee to send passcodes to a technician. Do not circulate one shared starter password or use a personal account to bypass access controls. Where conditional access requires a managed device or registered authentication method, plan the sequence so the user can complete enrolment without being trapped outside the only portal providing instructions.
In a hybrid environment, the source of the account might be a local directory synchronised to cloud services. A delay in synchronisation is not a reason to create a second unrelated identity. Trace the authoritative source, provisioning logs and destination account, then assign a resolution owner. A named exception should include the affected application, error or missing prerequisite, the person responsible and when the team will check again.
Microsoft Entra lifecycle workflows illustrate automated joiner, mover and leaver actions. Their scope, execution conditions and supported tasks must be configured; a successful run proves only that the relevant action reported its result. It does not independently establish that a worker has approved privileges or can perform every application task. Use the actual target system and the new starter's appropriate test to verify critical services.
Choose, configure and physically confirm the device
Check the actual approved hardware specification against the job: performance, memory, peripherals, accessibility and location. A standard laptop may be adequate for office work but inappropriate for specialist modelling, design or engineering. Verify stock or purchasing authority, supplier lead time and expected delivery. Record the asset tag, serial, model, assigned custodian and warranty in the approved asset system. A courier delivery scan is not the same as employee acceptance or a verified working machine.
Apply the organisation's current supported operating-system version, management enrolment, encryption, endpoint protection and configuration policies. Confirm that policies apply on the actual device and that its security condition is not merely a stale dashboard entry. For an inherited or reissued laptop, complete authorised data sanitisation and remove the previous person's identity or application sessions before assigning it. Reuse should not expose a prior worker's documents or authentication material.
Prepare required accessories, power supply and network support. A home worker might need a secure method for initial connection and an out-of-band contact route. Record what is physically ready and what remains in transit or awaiting testing. If a specific peripheral or licence is unavailable, communicate a realistic workaround only after the responsible manager accepts the effect on actual work.
Validate applications and everyday work rather than installations
Use the approved role list to install essential collaboration, communication, line-of-business and specialist tools. Confirm that any extra licence exists, is assigned to the correct identity and is activated in the right environment. A desktop icon or successful installer does not prove the employee can access the real service. Many applications also require a separate business owner, group membership, network route, certificate or supplier approval.
Choose representative tasks with the manager. A suitable first-day acceptance test might include signing in, opening a legitimate shared resource, joining the communication service, completing a safe transaction in the main application and using a required peripheral. Protect personal and customer information by using permitted test data and roles. Do not borrow a former employee's login merely to demonstrate that a screen opens.
Document outcomes per task and application. If email works but a finance application fails, the handover should record that partial readiness without hiding the dependency. A vendor ticket acknowledgement does not mean the entitlement was granted; retain its reference and check the destination when notified. Where several workflows depend on the same approval, one explicit blocker is clearer than many duplicated overdue notifications.
Coordinate the workspace, support route and first-day handover
New-starter readiness includes the working environment around the device. Confirm the intended desk or remote work arrangement, connectivity, display, audio, approved accessories and any essential site access. Ensure the employee has accessible information on secure sign-in, ordinary account recovery, suspicious messages and lost-device reporting. A helpdesk contact that requires a corporate login cannot be the only way to report a failed first login.
Provide a concise handover: what equipment was issued, which accounts are ready, what has been tested, who can approve further access and where to seek help. The employee should not be expected to diagnose identity federation or vendor configuration on the first day. For specialist roles, arrange a time with the relevant application owner rather than assuming a general helpdesk technician can validate every workflow.
Security orientation should explain why authentication codes and passwords must not be shared, where approved business data belongs and what to do when a convenient workaround would bypass organisational policy. The aim is usable guidance, not a generic lecture. Confirm the employee can use the approved support route before closing the corresponding readiness task.
Manage incomplete, urgent and changed requests honestly
Late starter notifications, changing start dates and unavailable suppliers are common. Keep each unresolved item attached to the person, affected service, owner, evidence and next check. Distinguish a pending decision from a failed technical implementation. The former needs business approval; the latter may need diagnostic work or escalation. Do not change a status to ready merely because the calendar date has arrived or an automation has run.
A replacement starter or changed role can invalidate an earlier equipment or entitlement plan. Reconfirm authorisation rather than recycling access assumptions. If a colleague changes departments, treat it as a mover event and remove access no longer needed while adding newly approved entitlements. A contractor's short engagement should include the agreed expiry and offboarding responsibility; long-lived permissions should not be the default response to a tight deadline.
Where operational work can proceed through an authorised temporary arrangement, explain its restrictions and owner. Do not grant privileged rights or bypass multifactor controls to create an appearance of punctual completion. Provide the client manager with an accurate summary of which essential tasks the new employee can perform and which are awaiting resolution.
Reconcile evidence, review failures and improve the next joiner
At handover, compare the original approved request with actual results: account status, group and application access, device custody, configuration, first-day user tests and outstanding issues. Technical logs and manager authorisation are complementary evidence; neither replaces the other. If the starter can perform core work but an optional item is delayed, record the agreed acceptance boundary and a follow-up owner. If essential work remains blocked, make that material condition visible.
Review repeated root causes with the client's managers. Common issues include late approval, missing software ownership, stale role templates, equipment lead times and incomplete vendor handovers. Improve the request form and supporting catalogue rather than asserting a productivity saving without measured evidence. Link each new starter to future role reviews and authorised offboarding so old access and assets do not remain indefinitely assigned.
Verified primary references: UK National Cyber Security Centre, Introduction to identity and access management supplies identity and privilege principles; Microsoft Learn, What are lifecycle workflows? describes one vendor's configured joiner automation. Neither independently certifies an MSP's particular onboarding service or a customer's first-day readiness. The relevant test is the combination of authorised scope and a functioning user workflow.
New-starter IT readiness: approved access versus automated provisioning
A new starter needs both permission to use a system and a working technical account. These are separate checks: a completed automation run cannot authorise an entitlement that the business has not approved, whilst a signed manager request does not establish that the intended account, device or third-party application is usable. This comparison helps a small MSP decide who owns a remaining blocker before the employee's first day.
| Readiness check | Business-authorised access | Technical provisioning and verification |
|---|---|---|
| Initial trigger | Manager confirms role, start date, named user and approved systems. | Configured joiner workflow or technician creates accounts within authorised scope. |
| Authority boundary | Approval determines which information, groups and privileges are appropriate. | A task run cannot grant commercial or security approval merely because it executes. |
| Evidence produced | Recorded approver, requested entitlement and any exception owner. | Account creation results, effective permissions, device compliance and tested sign-in. |
| Third-party applications | Application owner confirms legitimate licence and role needs. | Separate provisioning or integration must be verified in the actual destination. |
| When to mark ready | Required work is authorised; outstanding decisions are visible. | Representative user tasks work, or named unresolved blockers have a safe workaround. |
Practical decision: If no approved entitlement exists, return to the business owner rather than guessing another employee's privileges. If approval exists but the account is absent, inspect the provisioning task, its scope, prerequisites and target-system result. An identity-platform 'success' should not be reported as whole-role readiness until the user can perform agreed tasks. For a remote joiner, include a support route that works before corporate sign-in. Do not use another person's login or transmit passwords through ordinary tickets to make a deadline appear met.
Source A — authorisation and identity policy: UK National Cyber Security Centre, Introduction to identity and access management (official UK guidance, checked 1 November 2026) explains joiners, movers, leavers, least privilege and the distinction between identity, permissions and administration. It supplies security principles, not a particular MSP's onboarding SLA. Source B — automated joiner tasks: Microsoft Learn, What are lifecycle workflows? (vendor documentation, checked 1 November 2026) describes rule-scoped Entra joiner/mover/leaver tasks. This is one platform example; its completion does not demonstrate every external application has been provisioned. Image decision — fallback (a): the existing Founders Cube workstations photo is an attributed CC BY-SA 4.0 illustration of a prepared workplace, not a real client's onboarding setup. The caption explains that limitation.
Frequently asked questions
What should a manager provide before a new employee starts?
Confirmed role, start date, workplace, authorised systems, equipment needs, approved business owner and a route to decide exceptional access or software purchases.
Should IT copy another staff member's account permissions?
No. Use the current approved role requirements and confirm effective privileges. Copied historical permissions may be excessive or no longer appropriate.
Does Microsoft Entra automation set up every application?
No. Its workflows apply to supported configured tasks, identities and connections. Verify each important third-party application and respect licensing prerequisites.
What if the laptop arrives but the employee cannot sign in?
Keep onboarding visibly incomplete, use the authorised identity recovery and support process and assign ownership. Do not request passwords or authentication codes through informal channels.
What proves first-day readiness?
The person can perform representative approved work using managed equipment and actual applications, with required security controls present and any remaining dependencies explicitly owned.