Run the day with Conductor.

Contents

1. Start and sign in

1. Open app.conductordispatch.com. Use a current browser with a working secure internet connection.
2. Select Sign in and choose your Conductor Microsoft work account. Initial administrators are james.powell@conductordispatch.com and jaliyah.perry@conductordispatch.com. Complete your existing MFA yourself.
3. Verify the account shown in the header before making changes. If RLV keeps signing in automatically, use a separate Chrome profile or a separate Incognito window for Conductor. Do not sign out or reset the existing RLV tenant just to switch Conductor.
4. Use Dispatch for the daily board; Fleet & team for drivers and vans; Operations records for passengers, sites, payers and contracts; Billing for the ledger; Operations records for company/depot settings; Communication for alerts; Getting started for guided configuration.

The website does not save business actions offline. A displayed shell, a service-health response, or a successful Microsoft login does not by itself prove that a write was saved. Confirm the resulting record after a save. Do not repeatedly submit an uncertain write.

Getting-started wizard and consistent controls

Open Getting started. Work through Company, Depot & routing, Drivers & vans, Contracts, Communication and Review. Save and continue stores the current form plus progress; reopening resumes the saved step. Back or a step tab changes position but does not save unsaved field edits. Finish by reviewing the computed checks and pilot-limit acknowledgement; missing readiness is not bypassed.

The same application header, navigation and account area appear throughout. Search and Show inactive are on the left of record lists; Add is on the right. Each record has Open / edit on the right. Editors use Close in the heading, Cancel and the primary Save button in the footer. Driver/vehicle forms in the wizard are the same forms used in Fleet & team. Creating a driver record does not create a Microsoft account or verify qualifications. Completing setup is configuration review, not operational/privacy acceptance or broker approval.

2. Users and permissions

Microsoft Global Administrator, Azure Owner and a Conductor application role are separate concepts. A user must have access to the Conductor application and the appropriate app role. For a driver, management also links the correct Microsoft user object ID to one active driver record. A name or email match alone is not identity proof.

1. An authorized Microsoft administrator creates or invites the intended user in the Conductor tenant, using the organization's approved process.
2. Assign the Conductor RLV Pilot enterprise application's driver or dispatcher role. Do not grant Global Administrator merely to use dispatch.
3. For a driver, copy that user's exact Microsoft object ID into the driver record under Fleet & team. Verify it is the right person; duplicate IDs are rejected.
4. Have the person sign in and test the correct data boundary before giving them live work. Retiring the driver prevents driver-bound API access; revoke unused integration keys separately.

Do not create new tenants, remove domains, disable MFA or change recovery information as an access troubleshooting shortcut.

3. Depot, routing allowances and invoice identity

Open Operations records → Company, depot and invoice settings.

1. Set the shared depot. The RLV starting address confirmed by James is 4291 Miami Church Road, Concord, NC 28025. This is editable, not hard-coded per driver.
2. Choose the operational IANA time zone. RLV uses America/New_York. Service dates are calendar dates; pickup instants have an explicit UTC offset.
3. Review loading/unloading minutes and the traffic safety allowance. Defaults are ten minutes loading, ten unloading and twenty percent driving-time allowance. These are planning inputs, not a guarantee.
4. Choose whether to reserve return travel to the depot after the final trip. If off, the final release location is the last dropoff. Do not assume a return journey was reserved.
5. Enter the verified invoice seller legal name, address and contact details. Do not invent banking details or tax rates. Issuing an invoice snapshots these details; later settings changes do not rewrite issued invoices.
6. Save. A version conflict means someone changed the settings; refresh and review before retrying.

Changing an address does not physically move a driver or van. Confirm effective staging locations in Fleet & team.

4. Drivers and fleet

Open Fleet & team. Search the compact lists, open or edit a record, add a new driver/vehicle, and use Show inactive to find retired resources. Retire with status inactive; preserve historical IDs.

Driver record

Enter the verified name/contact information, active status, confirmed qualifications and correct Microsoft object ID. Capabilities are comma-separated exact labels, for example ambulatory or wheelchair; only record qualifications management has verified. Availability limits apply to departure/return travel as well as passenger time.

Flexible starting locations

A blank starting-location override uses the shared depot. Set an override when that driver or van is staged elsewhere. If confirming a new current location after earlier trips, also set Starting location effective from. Later trips use preceding relevant trip dropoffs/reservations unless a newer confirmed location takes precedence. Both the driver and the van must be positioned consistently.

If the driver and van start in different places, automatic assignment fails closed and requests repositioning review. Conductor does not silently invent a ride to collect the van. Arrange and confirm that movement, update the actual location when appropriate, or use an explicitly authorized administrator routing exception through the API with an audited reason. That exception is not a validated route.

Vehicle record

Use the actual unit name, usable passenger capacity excluding the driver, plate/VIN and verified capabilities. Set inactive for a resource that should not be selected. Unknown passenger capacity may remain blank only while the van is inactive. It appears as Passenger capacity not verified; activation requires a confirmed positive numeric capacity. Never use a guessed placeholder. Use Show inactive to review staged vans. Optional verified commercial dimensions can be supplied through the API in meters/kilograms; without them, a standard driving profile is not a guarantee of commercial-vehicle road clearance. Drivers must follow posted restrictions.

Contract restrictions and driver identity access

In Fleet & team or Getting started, Open / edit a driver or van. Under Restrict to these contracts, select the confirmed contracts that resource can work. No selections means unrestricted; it does not certify qualifications or compliance. Review the selections and save. Reopen the record to verify them. Existing selections, including inactive contracts, remain visible; a missing contract is labelled unavailable rather than silently removed. The API rejects references belonging to another operator or missing contracts.

Normal dispatchers may edit contact, availability and contract restrictions but cannot create, change or remove a driver’s Microsoft user object ID. That field requires an authorized identity administrator; the API enforces the same restriction even outside the website. Linking does not create a Microsoft account, assign an application role or alter MFA. Verify the intended person and role independently.

The wizard’s Review step identifies missing active drivers, vans and contracts, driver Microsoft links, and restricted resources with no active eligible contract. These are configuration checks, not operational acceptance or broker approval. A linked object ID alone does not prove a successful driver sign-in.

5. Keep contracts and states separate

Open Operations records. Create payers and sites, then separate contracts such as SafeRide NC, SafeRide VA, Modivcare NC and MTM. A state-specific program is its own agreement, not a renamed shared record. Enter verified payer references and external contract IDs. Duplicate external contract IDs are rejected within the organization.

Choose the correct contract on every trip and invoice. The dispatch board can show all contracts or one contract. Existing commitments across other contracts still block overlapping assignments. API-configured driver/vehicle contract approval lists restrict resource eligibility.

Passenger names, exact locations, phone numbers and trip documents are sensitive. Never put medical history, diagnoses, insurance images, card data or unnecessary personal information in general notes. Broker connection/approval is a separate onboarding task; adding a payer or contract does not establish a live feed.

Passenger and mobility-position limits

Fleet & team records Total passenger limit (exclude driver), Wheelchair positions and Stretcher positions. Mobility occupants are included within the total, not added on top. Blank mobility limits are unverified, not unlimited. Counts do not certify that every combination physically fits; verify each actual layout and securement requirements before use.

The trip editor separately records total passengers and wheelchair/stretcher positions needed. Include escorts in the total. A requested mobility position implies the corresponding driver/vehicle qualification even if a capability label was omitted. A wheelchair/stretcher capability label implies at least one position. Requests above the total or verified physical positions are rejected; a routing override cannot bypass those capacity checks. Release a scheduled assignment before changing these needs.

6. Create, edit, cancel and recur trips

1. On Dispatch, choose the service date and select Add trip.
2. Select the correct contract, enter authorized pickup/dropoff information and a precise pickup date/time, then seats and required capabilities.
3. Select Estimate passenger route and minimum minutes. Review its forecast and calculated minimum; assignment separately checks depot and inter-trip travel.
4. Save and verify the trip appears on its service date. If the response is uncertain, search/refresh first—do not create a second trip blindly.
5. Open a trip to inspect status, assignment, protected operations/attachments and recorded routing reservations.
6. Edit a scheduled unassigned trip through its edit control. For an assigned trip's route/time/capacity change, release its scheduled assignment, review the change, then replan/reassign.
7. Use the explicit confirmation panel to unassign or cancel. A started trip is not silently released. Cancellation is a recorded state event, not deletion of history.

Recurring weekday series are currently available through POST /trips/recurring. Supply recurrence.weekdays, untilDate and IANA timeZone; reuse recurrence.seriesId on a retry. Each instance receives its own date and local pickup time across DST; assignments are not copied. Ambiguous/nonexistent clock times require review. Maximum series window/occurrences are bounded to 366.

7. Routing and dispatch

1. Confirm depot/start locations, availability, qualifications, capacities and contract restrictions.
2. Select Plan assignments. The system produces proposals; it does not automatically commit them.
3. Review each proposed pair and any Needs attention explanation. Route evaluation covers passenger driving, loading/unloading, traffic allowance, positioning before/after the trip and relevant existing commitments across contracts/overnight work.
4. Confirm an individual proposal. The server revalidates it under an organization lock; a stale proposal can be rejected.
5. For a manually chosen pair, use the trip's assignment controls. The same safety checks still apply when routing is configured.
6. Inspect the saved routing reservation's departure/release times. Re-check after material route, staging, vehicle or schedule changes.

Plan batches are limited to ten trips with bounded candidate/time search. Confirm feasible proposals and run another batch. Route quotes cache for five minutes. The application defaults to 800 route estimates per month, including failed provider attempts; this is not a guarantee of a total Azure spending cap. Provider quotas/outages must be reviewed, not bypassed by invented drive times.

Ambiguous-address errors need a corrected full address or independently verified coordinates. Do not guess coordinates. Traffic forecasts and safety allowances cannot guarantee arrival or replace dispatcher/driver judgment.

8. Driver web workflow

Open Driver web with a linked active driver account. This is the browser version; native app publication remains on hold.

First sign-in

1. Open the Driver web link on your own phone or computer and select Sign in. For the RLV pilot, choose your existing @rentluxuryvans.com Microsoft work account, not a personal account or a shared administrator login.
2. Accept the one-time organization invitation if Microsoft requests it. Conductor's legal organization may display as APT Haul Corporation DBA Rent Luxury Vans. Complete any Microsoft verification yourself; never send anyone your password or verification code. Existing RLV passwords and recovery methods are not replaced.
3. Check that My route identifies your own driver name. No assigned trips is normal until dispatch assigns work. If a different account was selected, use a private browser window and the intended work account.
4. If access is inactive or not linked, contact your administrator. Directory invitation, Driver application role, the exact Conductor-tenant user object ID and an active driver record must all match. A home-tenant object ID is different from the Conductor guest object ID. Provisioning alone does not prove your first sign-in succeeded.

Assigned trips and available shifts

1. Verify the signed-in driver and assigned trip before starting work.
2. Review pickup/dropoff and time. Use the next enabled status action in order: Start trip → Arrived at pickup → Passenger picked up → Complete trip.
3. Verify the status was saved before continuing. When connection fails, do not assume the action was submitted. No offline queue of business/medical data is supported.
4. Add permitted inspection/receipt attachments and odometer records while securely connected to the correct trip.
5. Under Available shifts, choose the date, refresh and select Request shift. The list intentionally omits passenger names and exact locations. A request is interest/acknowledgement, not an assignment. Dispatch must still select a driver and van and validate travel.

A driver cannot view another driver's trip, cancel a trip, read billing or manage API keys. An administrator retiring a driver record immediately blocks that profile's API access without changing the driver's Microsoft password or MFA. Never use account sharing to work around an access or qualification failure.

9. Inspection photos, receipts and odometer records

The driver web screen supports trip-linked inspection photos, receipt attachments and odometer entries. Dispatcher trip details show protected metadata and temporary download links. Supported files: JPEG, PNG and PDF; maximum ten MiB each. Inspection-photo selection accepts images.

Uploads use a ten-minute, single-object intent; the browser uploads directly to private Azure Blob storage, then completes verification. Byte length, MIME and file signature are checked. This is not malware scanning or an inspection certification. Do not upload untrusted files or treat a photograph alone as a completed legal/compliance inspection.

Read links expire after five minutes and must not be pasted into public pages, Teams chats or logs. If upload completion is uncertain, retry the same intent through the API or ask management to check attachments before uploading again.

10. Teams alert timing and silencing

Default thresholds are shown above; change timing, enabled state, generic title/template and colors through Communication → Open / edit. SMS is visibly disabled and cannot be enabled without a separately integrated provider. The worker checks every five minutes. When catching up, it sends only the current most urgent stage, not a burst of old stages. Initial recipients are James and Jaliyah on conductordispatch.com. There is no default RLV driver broadcast and no UVA destination.

A scheduled departure's driver assignment, matching shift request or explicit acknowledgement suppresses unassigned alerts. Open Communication, select the unassigned trip, enter a reason, and acknowledge the alarm. This silences that departure but does not allocate a driver/van. Rescheduling creates a new timing context; an old request/acknowledgement does not silence the changed departure.

Withdrawing an acknowledgement or declining a request permits future due stages to resume if still unassigned. Previously accepted stages are not intentionally resent. Check delivery history: accepted is only HTTP acceptance; unknown may already have reached Teams and is not retried automatically. An authorized retry requires a reason and explicit duplicate-risk acknowledgement.

Dispatcher review of driver interest

Open Communication → Driver shift requests, or Review driver shift requests on the dispatch board. Search by driver, trip, contract or status; optionally filter the service date. Show reviewed / historical includes resolved requests. Open / edit uses the same Close, Cancel and Save layout as other editors.

1. Review the driver, exact requested departure, contract and request/history. A changed departure is clearly marked; an old request cannot acknowledge or silence the new time.
2. Choose Acknowledge, Decline or Withdraw and enter a reason of 3–300 characters. Acknowledge keeps the staffing alarm silent but does not assign a driver/van. Driver interest stops suppressing alarms if its requester becomes inactive, unqualified or unapproved for that contract. An explicit manager alarm acknowledgement remains a separate, reasoned override.
3. Use Open this trip in dispatch to review the actual trip and confirm a feasible routed assignment. Alert links also open the authorized trip and its correct service date.
4. Decline/withdraw allows future due alerts to resume only when no other active request/acknowledgement suppresses that departure. Already accepted alerts are not resent automatically.
5. If another dispatcher changed the record, saving returns a conflict. Close, refresh and compare; do not overwrite or blindly retry an uncertain result.

Driver-only available shifts omit names, exact addresses and free-text pickup areas. A van-only reservation still needs a driver and remains requestable. In the trip editor, Complete driver and van assignment keeps an existing reservation fixed and rechecks feasibility; unassign first only when changing that reserved resource. Setup-record editors also send version guards; integration clients should supply expectedVersion on updates.

Business-record backups and recovery

Open Operations records → Business-record backups. Refresh shows the last verified capture. Administrators can Verify today’s backup; this creates or reads today’s existing daily archive, not a new capture after every click. Later changes are included in the next daily export. Archives never download into browser storage.

A nightly 04:30 UTC job exports business records to a separate private, geo-redundant Microsoft storage account. Completed exports are read back, checksum checked and version identified. Exports are logical, not transactionally consistent point-in-time snapshots. Access keys, identity mappings, notification credentials, transient queues and attachment file bytes are excluded. Attachment metadata is included; primary attachment versioning/deletion recovery is separate.

Generated archives expire after 35 days; soft-delete recovery is 30 days and previous-version expiry is 65 days. Runtime backup access cannot delete blobs or read storage keys. Account-deletion locks require deliberate operator review to remove. Capture is bounded; oversized datasets fail visibly rather than truncate. After three scheduled failures, the system attempts one generic red notice through enabled/verified administrator Teams destinations, respecting the global Teams switch; no success spam or passenger information is sent.

There is no production restore button. A synthetic-only command verifies record and financial-field restoration into an empty isolated organization and strips driver Microsoft bindings. An actual recovery requires an operator-reviewed runbook, identity/credential reconfiguration and reconciliation before dispatch or financial processing resumes. These backups do not establish broker approval, HIPAA compliance or full disaster-recovery acceptance.

11. Connect and verify Teams Workflows

Use the new Conductor Microsoft tenant and the actual James/Jaliyah accounts. Do not modify existing RLV chats or use their credentials as the default destination.

1. In Conductor Teams, choose/create the intended private administrator chat and verify its members. Use Teams Workflows' webhook-to-chat template and configure the actual target chat.
2. Prefer a tenant-restricted trigger permitting the Conductor Function managed identity. Its service-principal object ID is c3c9e89a-bbf0-473d-ab47-6654cb82ba00; this is not the API application's client ID. If the chosen template only uses an Anyone secret URL, select that matching mode in Conductor.
3. Give the Workflow appropriate organizational ownership/co-ownership so it does not become orphaned when one owner leaves. Keep its trigger URL private.
4. Open Communication → Connect a Teams Workflow. Enter a label, primary administrator email and actual audience emails; paste the private URL and select the matching authentication mode. Save the connection disabled.
5. Select Send non-patient test alert. Check the result and personally verify that the card arrived in the intended private chat with exactly the authorized audience.
6. Only then check the receipt/membership confirmation and enable the destination.
7. To add an administrator, first update actual Teams chat membership or create a separate private Workflow. Edit the Conductor connection/audience; save disabled, retest and verify. Merely editing an email label cannot change Teams routing.

Credential URLs are stored in dedicated Azure Key Vault and are not returned by the API. Changing URL, audience or authentication mode clears prior test/receipt proof and requires a fresh test. Secret-URL mode omits the Authorization header; restricted-identity mode sends a Flow audience token.

Microsoft reference: Teams Workflow webhook messages and restricted trigger authentication.

12. Invoices, receipts and corrections

Open Billing. This ledger records your business documents and documented receipts; it does not charge a card, debit a bank, submit a broker claim, settle funds, issue a refund or send invoice emails.

1. Verify seller details in Settings. Create a draft with correct bill-to, contract/payer, dates, line descriptions, quantities, prices and applicable verified tax input.
2. Review the calculated cents. One invoice belongs to one contract; linked trips must agree. A trip cannot be billed twice across issued invoices.
3. Save the draft, then open it and explicitly issue it. The issued invoice receives a non-reused sequential number and becomes immutable. Number gaps may occur after an interrupted issue; numbers are not recycled.
4. Record a payment only after money was actually received. Enter the real receipt date, amount, method and reference. Partial receipts reduce balance; overpayment is rejected. Future cash receipts are rejected.
5. If a receipt record is wrong, reverse it with a reason/date. This corrects the ledger only; it does not refund the customer.
6. To void an issued invoice, first reverse any net receipts, then use the explicit void action and reason. Keep history; do not delete it.
7. Download the printable invoice HTML. Open it and use browser Print/Save as PDF if a PDF is needed. Conductor does not automatically generate or send a PDF in this pilot.

Drafts can be edited with version checks. Issued invoices cannot be rewritten to change prices, seller identity or customers. Reconcile an uncertain save using its retained idempotency key/record history before retrying. The CSV export contains the loaded invoice list, not only the financial-summary date period.

13. Read financial performance correctly

Choose From/Through on Billing. Review totals, contract breakdown, outstanding balance and aging buckets. Record documented costs with their incurred date/category/reference and contract/trip where known.

Totals use integer cents with explicit line rounding. Do not enter invented rates, expenses or balances to make reports appear complete. Compare exported records to the underlying invoices, actual receipts and accounting records before making financial decisions.

14. API, exports and integration boundaries

The API manual documents current routes, required scopes, input schemas, response types, error handling, safe retries and examples. Download OpenAPI JSON for tooling. API keys are server-only secrets; use Microsoft sign-in for the website.

Trip CSV exports enforce organization and driver boundaries. The RLV dry-run endpoint maps supplied booking data without reading/changing RLV. It does not establish a live integration. Webhook registration currently stores a future subscription and returns a secret once; no outbound delivery worker is connected. Do not rely on those registrations for live event delivery.

Broker integrations require authorized credentials, an agreed interface, mapping/reconciliation and written acceptance/testing with that broker. A generic API, branded website or payer record is not broker approval. Multi-tenant identity and customer self-service onboarding remain deferred until RLV validates the single-organization pilot.

15. Troubleshooting and recovery

• Wrong Microsoft account: use a separate Conductor browser profile/window and select the correct account. Do not reset the tenant, remove domains or change MFA/recovery.
• 403 / linked driver required: management checks application role, active driver status and exact linked Microsoft object ID.
• 409 / changed record: refresh and review. Do not overwrite a newer assignment/version or keep resubmitting.
• Route unavailable or ambiguous: confirm full addresses/coordinates, current depot/start locations, availability, qualifications, overlapping commitments, provider status and quota. Do not invent a feasible result.
• No Teams alert: check the correct tenant, enabled verified destination, Workflow ownership/target chat, request/ack suppression, due time and delivery history. HTTP acceptance is not human receipt.
• Unknown notification outcome: inspect Teams first. Only an administrator can authorize a duplicate-risk retry.
• Uncertain invoice/trip save: refresh/search and reconcile before another create. Keep the same idempotency key where supported.
• Attachment failure: confirm supported file type/size and matching intent; reuse a valid intent and check metadata before uploading duplicates.
• Disconnected: reconnect before submitting; no offline record queue is supported.

Support evidence should contain the requestId, time, screen/operation and sanitized error—not passwords, tokens, Workflow URLs, signed download links, patient records or financial-account numbers.

Operators own daily route/receipt verification. Administrators own access, notifications and settings. Engineering owns release regression, monitored failures, backups and recovery drills. Keep changes staged and tested; preserve source/checkpoints locally and in the approved shared record without copying secrets/caches.

16. Before using live work

1. James and Jaliyah confirm their own correct Microsoft accounts, MFA and Conductor admin access. An actual driver role/profile passes own-trip isolation tests.
2. Confirm the depot, per-resource locations, capacity, qualifications and actual contracts/rates. Test routing departure/return and conflicting assignments against real public addresses.
3. Both administrators verify the generic Teams test in the intended Conductor chat; only then enable delivery.
4. Reconcile a synthetic invoice, partial/full receipt, reversal, void, cost and historical aging/export. Confirm no actual charging or emailing is implied.
5. Verify desktop/phone-width create/edit, dispatch, driver events, private attachment access, reconnection/error paths and support references.
6. Management completes the required privacy/security, broker-interface and operational acceptance before real protected rider data or live broker trips. Record explicit pass/fail evidence.
7. Keep native app/store publication on hold until the website and operating acceptance pass. Do not describe the platform as approved by any broker without actual evidence.

The service being online is a technical milestone. Operational acceptance belongs to RLV and the relevant external organizations.