Questions agencies commonly ask before getting started.

WorkCura is a multi-tenant domiciliary care management web application designed to help care providers manage people, service users, care delivery, scheduling, visit execution, compliance, timesheets, workforce payments, client invoicing, communications, reporting and related operational records from one system.

It is designed primarily for domiciliary care agencies and their authorised teams. The platform provides separate experiences for Super Admin, agency management, care workers and authorised client or family portal users.

No. WorkCura records and supports care-management workflows, but it does not diagnose conditions, prescribe treatment, determine medication suitability or replace professional judgement. Agencies remain responsible for clinical governance, care quality, safeguarding, staff competence and compliance with applicable law and regulation.

It is a multi-tenant SaaS platform. Each subscribing agency operates inside its own tenant boundary. Agency-scoped database queries are designed to prevent one agency from accessing another agency’s operational records.

Yes. Agency managers can manage staff, clients, visits, care records, timesheets, worker payments, client invoices, reports, notifications, messages and administration. Care workers use a mobile-first workflow for assigned visits and related records.

Yes. The core model is intended to scale from smaller providers to larger teams. The applicable subscription plan may impose staff or client limits, so agencies should check the current plan details before subscribing.

No. The application is designed for UK and Ireland use rather than being hard-coded to a single English locality. However, each organisation remains responsible for applying the legal, regulatory and contractual requirements relevant to where it operates.

Yes. The public website includes a Book a Demo page where visitors can request a preferred date and time and choose either an online presentation or an on-site visit. A requested slot is not automatically confirmed; the team reviews the request and confirms availability.

The public website includes the Home, Pricing, About Us, Contact Us, FAQs, Terms and Conditions, Privacy Policy and Book a Demo areas, together with registration and sign-in routes. Public content is managed centrally by Super Admin.

A prospective agency uses the agency registration workflow, supplies the required organisation and account details, selects the applicable currency and plan or trial option where offered, and completes any required subscription steps.

Many agency settings can be updated from the agency administration area. Account-level or billing-sensitive changes may require additional verification or support depending on the field and subscription state.

After the worker record has been created and verified/activated by the agency, the manager can generate a one-time password setup link. The care worker uses that link to create a password and then signs in through the normal login page.

Yes. Agency managers can edit the care worker record before activation, including correcting the email address. The application performs duplicate-email checks because the email is used for access and account identity.

A one-time setup or reset link cannot be relied on indefinitely. The user should request or be issued a fresh link. This is a security measure intended to reduce the risk of an old link being reused.

Yes. Password reset is supported through the configured email delivery workflow. When SMTP is enabled, password-reset messages are queued through the application’s transactional email outbox.

No. Each user should use their own authorised account. Password sharing weakens auditability and can expose confidential client, workforce and financial information.

The principal platform experiences are Super Admin, Agency Manager, Care Worker/Employee and authorised Client/Family Portal user. Some agency workflows can also distinguish management responsibilities such as Agency Admin or Care Manager.

Super Admin manages platform-level matters such as agencies, subscriptions, public website content, requested demos, delivery configuration, operations, tests/readiness, errors and backups. Super Admin access should be restricted to appropriately authorised platform personnel.

No. Agency operational records are tenant-scoped. Staff, clients, visits, care records and related records are queried with the authenticated agency context so one agency should not have a global lookup into another agency’s data.

No. Care-worker access is oriented around their own assigned work and permitted employee functions. Sensitive management-only areas are not exposed simply because the worker belongs to the agency.

The portal is deliberately restricted. An authorised account can see information for the linked client such as scheduled visits, the latest approved care plan and issued/paid invoices. Internal payroll, staff compliance, confidential safeguarding material and management-only records are excluded.

Safeguarding cases are handled as restricted management records. Confidential management notes and outcomes are not displayed to care workers or ordinary client/family portal users.

No. Where historical care, audit or financial integrity matters, the platform uses archival or deactivation approaches rather than blindly destroying linked history. This helps preserve the record of what occurred.

A sensible onboarding sequence is: confirm organisation details; create job roles; configure visit types and rates; set mileage and monitoring rules; add and verify care workers; add clients; create care plans/medications where applicable; then begin scheduling visits.

Yes. Job roles are reusable agency-specific records used when creating staff and in visit-type configuration.

Yes. Agency Manager → Administration → Create Visit Type provides a dedicated page to create and manage visit types.

A visit type can include a visit name, job-role applicability, rate category, employee pay rate, client charge rate, description and status. These values can be reused during visit scheduling.

They represent different commercial relationships. The employee pay rate supports workforce pay calculations, while the client charge rate supports client billing. One should not be assumed to equal the other.

Deletion is controlled because historical visits may depend on that configuration. Where a record is in use, deactivation or safe-delete rules prevent changes from corrupting historical records.

Yes, but historical transactions should retain the rate snapshot that applied when the relevant visit or financial record was created. Later rate changes are intended to affect future activity rather than rewriting past payroll or billing history.

Yes. Agency setup includes visit monitoring and escalation settings such as late check-in thresholds, missed-visit rules and unassigned-visit alert timing.

Staff records can include identity and contact details, emergency contact, employment information, job role, qualifications, training, DBS/background summary, right-to-work summary, professional registration, skills, languages, driving information and management notes.

The application supports statuses including Active, Inactive, Suspended, Pending verification and Locked. The exact permitted transition depends on the management workflow.

Yes. This is specifically supported so errors such as an incorrect email address can be corrected before the worker receives access.

Agency managers can remove a care worker from the active management list through the application’s archive/deactivation workflow. Historical records are retained, linked access is deactivated, and upcoming visits must be resolved before removal.

Removing a worker who still has upcoming assignments could leave visits incorrectly allocated. The system requires those visits to be reassigned or cancelled first.

The worker should first be reviewed/verified according to the agency’s process. Once activation requirements are satisfied, the manager can activate the worker and issue a one-time password setup link.

Assignment logic is intended to restrict new care delivery to eligible active workers. Managers should also review outstanding visits whenever a worker’s employment or compliance status changes.

No. It can hold operational workforce information and compliance records, but agencies should decide which employment documents belong in WorkCura and which must remain in their formal HR system or personnel file.

The platform can store staff documents and expiry-related records for areas such as qualifications, training, DBS/background checks, right to work and professional registration, depending on how the agency configures its requirements.

Yes. Visit assignment logic can reject a worker with expired active mandatory compliance documentation.

No. The platform can surface records and apply configured workflow rules, but the agency remains responsible for assessing competence, supervision, regulatory eligibility and role-specific training.

The manager should follow the agency’s compliance process, obtain updated evidence, review whether the worker may continue to work and update the record. The system should not be treated as a substitute for management action.

Yes. Recurring generation respects worker eligibility checks such as overlap, recorded absence and expired mandatory compliance.

Yes. Archiving is designed to preserve necessary history rather than destroying the evidential chain associated with past assignments and care delivery.

Client records can include contact details, address, emergency contacts, GP information, next of kin, authorised representative details, care needs, risks, communication preferences, funding information and other operational care information.

Yes. Client records are managed within the agency tenant and can be updated by authorised management users.

Agency managers can archive/remove a client from the active management list. Historical clinical, care and financial records are retained, linked portal access is revoked, and upcoming visits must be cancelled or otherwise resolved first.

Care records, invoices, incidents and audit events may need to remain historically accurate. A soft archive avoids breaking linked records while removing the person from normal active workflows.

Yes. Client data supports authorised-representative information, and a restricted client/family portal account can be created where appropriate.

No. The client/family portal is intentionally limited and should not be assumed to expose every field from the agency’s internal client record.

Yes. Agencies can create tenant-scoped care assessments covering required assessment domains, review dates, status, assessor attribution and amendment reasons.

The assessment workflow is designed to preserve version history so changes can be traced instead of silently overwriting the historical record.

Yes. Care plans can be versioned, reviewed, approved and amended. The latest approved care plan can be made available to an authorised client/family portal user.

The exact view depends on the worker workflow and access design. Agencies should ensure workers have the care information necessary for safe delivery without exposing unrelated confidential management material.

No. Approval is an organisational workflow action. Clinical/professional responsibility remains with the authorised persons within the care provider.

The agency should create or approve the revised version, record the reason for amendment and ensure relevant workers are informed according to the organisation’s change-control and communication process.

Yes. Agency management can record medication name, dosage, frequency, route, start/end dates, instructions, prescriber and status.

No. The staff record includes a Medication support authorised control. Medication-support recording is restricted to workers whose record indicates that they are authorised.

No. WorkCura does not prescribe or determine whether medication should be administered. It records configured medication information and care-worker support outcomes.

Submitted medication-support records are designed to be immutable so the audit history reflects what was recorded at the time.

Historical medication-support records retain a snapshot of the medication details relevant when the record was made. Managers should update the active medication record for future care.

The worker should follow agency policy, avoid making an unsafe assumption, contact an authorised manager or clinician as appropriate and use the incident/exception process where required. The application itself is not a substitute for escalation.

A visit normally includes the client, scheduled date, start/end time, visit type, location/instructions, required tasks and, where applicable, an assigned care worker.

Yes. Unassigned visits are supported and can be filtered from Agency Manager → Care Delivery → Visits using the Unassigned status option.

Assignment logic verifies that the worker belongs to the agency, is active/eligible, does not overlap another visit and does not have blocking mandatory compliance or recorded absence conditions.

The system is designed to prevent overlapping assignments for the same worker.

Scheduled duration is calculated server-side from the visit start and end times.

Yes. The Visits page includes an Unassigned filter based on visits where no staff member is assigned.

Historical care delivery should not be treated like an editable diary entry. The platform uses controlled status, exception and audit workflows to preserve the integrity of completed activity.

It is a reusable schedule definition for repeat care, such as daily or weekly visits. The template can generate individual future visits while preventing duplicate occurrences.

Yes. Agency managers can use the Edit action on each recurring template to change supported fields such as client, worker, pattern, weekdays, dates, time, visit type and instructions.

No. Editing the template affects subsequent generation. Existing individual visits remain as previously generated and must be reviewed separately if the change should also apply to them.

This protects historical and near-term schedules from being silently rewritten when a recurring pattern changes.

It creates future visit occurrences from the recurring template for the configured generation period, subject to duplicate-safe and eligibility controls.

Yes. A template can be paused/deactivated so new occurrences are not generated until it is reactivated.

The rota gives agency management an operational weekly view of scheduled care work and supports planning across workers and service users.

Yes. The generation workflow respects recorded absence, worker overlap and expired mandatory compliance conditions.

The dashboard provides navigation to My visits, My timesheets, My profile, Messages and Notifications, together with an Upcoming section containing current-day and future assigned visits.

It was intentionally removed to avoid an unnecessary empty area. Today’s visits now appear within the Upcoming list in chronological order.

The Upcoming list displays “Today —” immediately before the service user’s name for visits scheduled on the current date.

Yes. It is mobile-first and intended to work well in supported mobile browsers.

The platform supports Progressive Web App behaviour. On supported devices and browsers, users may be able to install it to the home screen and launch it in an app-like window.

No. Installable PWA behaviour does not mean that care records can safely be completed without connectivity. Many workflows require a live authenticated connection to the server.

A worker can review the permitted visit details in advance, but journey and check-in controls become available according to the scheduled-day rules.

From an assigned visit, the worker can start the journey when the visit becomes eligible, then check in at the appropriate stage, complete required care actions and check out.

Future visits can be reviewed, but journey/check-in controls are restricted until the scheduled day according to the platform’s visit-availability rules.

The application requires earlier same-day visits to be resolved before a later visit is started or checked into. This reduces the risk of silently abandoning a previous scheduled call.

Completion or an approved/recognised exception state can allow the sequence to continue, depending on the workflow. Simply ignoring the earlier visit is not treated as resolution.

Location capture is user-initiated and optional unless the deployment/agency policy requires it. Users should understand what their organisation expects before relying on location information.

Yes. The visit workflow supports timestamped notes and task-result recording within the assigned visit.

Check-out closes the active delivery phase and contributes to the record used for visit history and, where applicable, timesheet information.

A worker can submit a cancellation request, but submission does not itself cancel the visit. The worker remains responsible until the agency manager approves the request or reallocates the visit.

Domiciliary care continuity requires management control. The agency needs an opportunity to assess risk, arrange replacement cover and document the decision.

Yes. The workflow supports an agency notice-hours setting. Short-notice requests can be escalated urgently.

It allows the worker to submit a manager exception request explaining why the visit genuinely cannot be performed or completed. An authorised manager must review the exception.

No. It creates a controlled request for management review; it is not a self-authorised skip.

Where the workflow allows and the request has not already been finalised, the worker can withdraw the request. Managers should still verify the visit’s current assignment state.

The visit can return to an unassigned/reallocation state so management can arrange replacement care, with the decision preserved in the audit trail.

Yes. Incident reporting is available from the visit workflow so the event can be tied to the relevant client, worker and visit context.

Agency management can review the incident in the management incident area, record the response and take any necessary operational or safeguarding action.

A safeguarding concern can create a restricted safeguarding case for management review.

No. Confidential safeguarding notes and management outcomes are restricted and are not exposed back to the ordinary care-worker portal.

No. If immediate harm, medical emergency or safeguarding risk exists, users must follow emergency procedures and organisational policy. Recording the event in WorkCura is not a substitute for urgent action.

Yes. Safety-related submissions and management actions are intended to be attributable and auditable.

Timesheets are created from completed visit activity through the care-worker timesheet area.

The platform records visit check-in/check-out information and can derive worked time for operational reference. The current pay rule uses the scheduled visit duration for guaranteed visit pay rather than reducing pay because a visit finished early.

The employee pay calculation uses the visit’s snapshotted employee rate and scheduled duration. Mileage and approved expenses can be included separately where configured.

A snapshot preserves the rate that applied to a historical visit so changing today’s visit-type rate does not rewrite old payroll records.

Yes. Agency managers have a timesheet review workflow and can approve, reject and later mark approved items as paid.

Yes. Agency managers can configure an employee mileage rate, and the applicable rate can be snapshotted for payroll history.

The workforce-pay module creates and manages worker-payment information. The agency remains responsible for its payroll/payment process unless a separately configured payment integration expressly provides otherwise.

No. Workforce pay and client charging are separate. They may arise from the same care visit but use different rates and financial records.

Yes. Agency management can create and manage client invoices using visit-related charge information.

The client charge rate configured for the relevant visit type can be snapshotted onto visit/billing records so later changes do not alter historical amounts.

Yes. The invoice workflow supports states/actions such as draft creation, issue, payment marking and voiding, subject to the current screen and permissions.

The invoice detail workflow includes a Print / Save PDF option through the browser’s print facilities.

An authorised client/representative portal can see issued or paid invoices linked to that client, while internal agency financial management data remains restricted.

No. Agencies remain responsible for accounting treatment, VAT/tax decisions, funding rules, invoice correctness and statutory record-keeping.

Yes. The in-app Notification Centre is the authoritative notification record for authenticated users.

Examples include visit assignment and changes, rota generation, exceptions, incidents/safeguarding alerts, timesheet review outcomes, payment confirmation and secure-message activity.

Yes, where SMTP delivery is configured and the relevant notification preferences are enabled.

Yes. The platform includes optional SMS notification/escalation delivery when the required provider configuration is present.

External delivery uses queued/retry behaviour so a provider failure does not normally stop the underlying care workflow. The in-app record remains the primary application notification.

Notifications should minimise sensitive content. Users should sign in securely to view detailed information rather than relying on ordinary email or SMS for confidential care records.

Agency Admins/Care Managers can message active care workers in their tenant, and active care workers can message authorised management users.

No. Messaging is tenant-scoped and participant access is restricted.

No. Thread history is participant-restricted.

Yes. A new secure message can create an in-app notification linking the recipient to the thread.

No. It is an operational communication channel, not an emergency-response service. Urgent safety matters should follow the agency’s emergency escalation procedures.

Message records are tenant-scoped and actions are logged to support traceability.

An authorised agency manager creates portal access from the relevant client profile and issues the account/setup link through the supported access workflow.

The portal is limited to the linked client’s permitted information, including scheduled visits, the latest approved care plan and issued/paid invoices.

No. The portal is read-only for these care-management records.

No. Payroll, staff compliance and management-only workforce information are excluded.

No. Restricted safeguarding material and confidential management notes are not part of ordinary portal access.

The agency should promptly revoke or deactivate that portal access and follow its own governance process for reviewing any continuing lawful basis.

The SaaS layer supports configurable subscription plans, agency subscription states and billing visibility. Live payment collection can be enabled through Stripe.

Yes. Plans can be configured with monthly and annual Stripe Price IDs where those billing cycles are offered.

The platform supports separate GBP and EUR plan pricing, with the agency’s selected currency stored for the subscription and relevant new financial records.

Yes. The subscription framework supports a configurable trial period. The exact trial duration and limitations should be taken from the current registration/pricing information rather than assumed from an older document.

Where subscription enforcement is enabled, agency access can be restricted according to subscription state and the platform’s configured enforcement rules.

Stripe webhooks update customer/subscription identifiers, payment success/failure, period dates, cancellation and subscription state in WorkCura.

Card payment details are handled through Stripe’s payment interfaces rather than being designed for direct storage in the WorkCura application database.

Yes. Super Admin has platform subscription management and billing oversight functions, while agencies can view/manage their own subscription where enabled.

Open Book a Demo, enter your organisation/contact details, select a preferred date and time, choose the preferred format and submit the request.

Yes. Select Online presentation to request a remote video meeting.

Yes. Select Visit our organisation and provide the organisation address, including postcode. Travel arrangements are confirmed separately.

No. It is a preferred appointment request. The team reviews availability and contacts you to confirm the meeting.

You can identify your organisation, contact details, approximate workforce, meeting format, preferred appointment and anything you would particularly like demonstrated.

The request is stored in the platform and appears in Super Admin → Public Pages → Requested Demos. Where email delivery is configured, a notification is also queued to the configured destination address.

Yes. The Requested Demos area allows Super Admin to configure the destination email address for new requests.

The current workflow supports New, Contacted, Booked, Completed and Cancelled.

Super Admin oversees agencies, SaaS plans/subscriptions, public content, requested demos, email/SMS delivery configuration, operational checks, tests/readiness, error records and backup/restore functions.

Yes. Public Pages provides editors for the website content. Published content is stored in the platform and can be updated without editing template files directly.

Yes. The public content tooling supports managed hero media and public branding assets, subject to the specific page/media controls available.

Yes. The platform records application errors with references so support can correlate a user-facing reference with operational diagnostics.

The global error-handling approach is designed to record errors and return a controlled error page rather than exposing a raw stack trace to ordinary users.

Yes. Super Admin has operational Tests & Readiness functionality, and the codebase includes build, route, security and production-readiness checks.

Yes. The platform includes database backup and guarded restore tooling, with integrity checks and private storage outside the public web directory.

Yes. A backup strategy is incomplete unless restoration has been tested in a safe environment. Production restore operations should follow the organisation’s change-control and disaster-recovery procedure.

Depending on the workflow, the platform may process agency contacts, staff records, client/service-user information, care assessments, care plans, medication data, incident/safeguarding information, visit records, location information, timesheets, finance records, messages, portal information and technical/audit data.

Yes. Where agencies use care-plan, medication and care-record features, the platform can process health and other special-category personal data. Agencies must ensure they have an appropriate lawful basis and governance framework for the data they enter.

The answer depends on the processing activity. A subscribing care provider will ordinarily determine the purposes and means of its own workforce/client care data and therefore has controller responsibilities for that data. The platform provider may act as processor for customer-controlled data and controller for its own website, account, security and business-administration purposes. The Privacy Policy and applicable data-processing agreement should be reviewed for the precise allocation.

The application uses hashed passwords and authenticated session/token controls. Users should still use strong unique passwords and protect their devices.

Yes. Server-rendered POST actions are protected with CSRF tokens to reduce cross-site request forgery risk.

Yes. The application uses security middleware and protective HTTP-header controls as part of its production hardening.

Yes. Important management, care, subscription and security-relevant actions are logged to support traceability.

No. Users should avoid sending passwords, payment-card details or confidential care records through ordinary email unless specifically instructed to use an approved secure process.

The public Privacy Policy explains the categories of personal data, purposes, controller/processor roles, retention, rights, subprocessors and security approach in more detail.

No. WorkCura is a web application accessed through a supported browser. PWA installation is optional where supported.

Modern desktop, laptop, tablet and smartphone browsers can access the platform, subject to normal browser support, screen size and organisational device policy.

Browsers can cache older CSS or JavaScript. A hard refresh or clearing cached site data may be needed after a deployment, especially where the release updated front-end assets.

Some interactive features such as calendars, video controls and dynamic form behaviour rely on JavaScript. Core server-side security and validation do not rely solely on client-side checks.

No web service can guarantee uninterrupted availability. Maintenance, hosting incidents, network failures, provider outages or circumstances outside reasonable control can temporarily affect access.

Care workflows should continue because outbound notification delivery is queued and retried. Users should rely on the in-app system and established operational escalation channels.

Yes. The application exposes operational health information used in deployment and readiness checks.

Confirm the correct email, password and role-specific account status. Check whether the account has been activated, suspended or locked. If the password is forgotten, use the reset process or ask an authorised manager to issue the appropriate setup/reset link.

Record the reference and the action you were performing. Do not repeatedly submit sensitive data. An authorised administrator can use the error log/Hostinger application log to locate the underlying error by reference.

Perform a hard refresh and, if necessary, clear cached site assets or restart the installed PWA so the latest release-versioned CSS and JavaScript are loaded.

Common causes include inactive status, overlapping work, absence, expired mandatory compliance or the worker not belonging to the same agency. Review the staff record and visit schedule.

No. Recurring-template edits intentionally affect future generation only. Already-generated visits retain their own details and need to be changed individually if required.

Check for upcoming visits or other blocking operational relationships. Future care must first be reassigned, cancelled or otherwise resolved.

The application may be enforcing same-day sequencing because an earlier visit remains unresolved. Complete the earlier visit or follow the manager exception/cancellation process.

Not necessarily. External delivery is asynchronous. Check the in-app notification, delivery/outbox status and provider configuration. The care workflow can succeed even if an external message needs retrying.

No, provided the submission succeeded. Demo requests are stored in the database first. Email notification is an additional delivery step and can fail/retry independently.

Use the Contact Us page or your contracted support channel. Existing customers should provide a concise description, relevant non-sensitive reference number, affected role/page and approximate time of the issue.

Scheduling, medication support, payroll, invoicing and care history all depend on accurate source records. Incorrect dates, rates, email addresses or client information can propagate into later workflows.

The agency remains responsible for the accuracy and appropriateness of the information its users enter. WorkCura can validate formats and workflow conditions but cannot know whether a real-world fact is correct.

No. Use controlled corrections, amendment reasons and supported status workflows. Historical records should remain traceable.

Immutability protects the evidential value of records such as medication-support outcomes and other completed care activity. Corrections should be handled through approved amendment or incident processes rather than silent rewriting.

Start with clean configuration, define roles and rates, verify a small staff/client sample, run test visits end-to-end, test employee mobile workflows, review reports and financial outputs, then expand deployment in a controlled manner.

Yes. After deployment, verify the critical workflows used by the organisation, especially login, scheduling, worker visit execution, timesheets, notifications, invoicing and any functionality specifically changed in the release.

Yes. When requesting a demo, visitors can state what they particularly want demonstrated, such as scheduling, electronic care records, timesheets, invoicing or compliance.

Yes. The Book a Demo page supports an on-site request. It remains subject to confirmation and travel arrangements.

The website includes a Pricing page. Actual fees, plan limits, currencies and billing cycles should be taken from the current published pricing or contractual order, because plans can change over time.

Where a trial is currently offered, the registration/pricing flow will show the applicable duration and terms. Do not rely on an old screenshot or manual for the live trial period.

Prepare organisation details, an authorised admin contact, job-role list, visit-type/rate structure, staff data, compliance requirements, client data, scheduling rules, notification preferences and a plan for data-protection/governance review.

A migration is a separate project decision. Data should not be imported blindly; fields, retention requirements, lawful basis, duplicates and historical integrity should be mapped and validated before migration.

Not necessarily. WorkCura covers a broad care-management workflow, but each organisation should assess whether it also needs specialist HR, accounting, clinical, payroll, rostering or regulatory systems and how those responsibilities are divided.

No. The platform can support record-keeping and controls, but compliance depends on the agency’s policies, staff competence, governance, lawful processing, supervision and use of the system.

No single software status replaces managerial judgement. Managers must review the underlying evidence and ensure the person is suitable for the particular role, client and task.

No. Automated monitoring supports oversight but should complement, not replace, operational management, telephone escalation, on-call arrangements and emergency procedures.

No. Legal, employment, regulatory, tax and data-protection questions should be considered with appropriately qualified advisers where necessary.

No. The application records care information and workflow outcomes. Medical decisions should be made by appropriately qualified professionals.

Follow the agency’s business-continuity and downtime procedure, record necessary care information safely through the approved fallback method, and reconcile the record when the system is available again.

No. Apply least-privilege access. Users should receive only the role and permissions needed for their responsibilities.