Skip to main content
Security and data review

Review the actual controls behind the workflow—not a collection of borrowed badges.

Ironline protects service-business records through workspace scope, role-aware access, private customer paths, evidence-based financial state, visible support access, controlled provider integrations, and fail-closed operating boundaries.

Read the Privacy Policy

Workspace-separated

Each business owns its operating records inside a workspace with membership and role checks.

Evidence-aware

Financial, provider, migration, and automation state is qualified by evidence and reconciliation.

Failure-visible

Uncertain or unsupported outcomes remain visible, paused, rejected, or reviewable instead of being silently called successful.

Current control model

Security is built into the handoffs that can change customer, access, or financial state.

Access

Workspace and role boundaries

Customer and operating records are scoped to a workspace. Owners, managers, office/dispatch staff, technicians, and read-only users receive different permissions while staff, sales, and platform administration remain separate surfaces.

Customer and files

Private records and scoped links

Private attachments use authorized application flows. Customer request, estimate, invoice, and Customer Center links use opaque routes, remain outside the public search index, and do not expose the internal workspace.

Financial integrity

Provider evidence before financial state

A redirect or button click is not enough to mark an invoice paid. Provider-backed payments, refunds, and disputes retain provider identifiers and reconciliation state; authorized manual records remain visibly manual.

Accountability

Visible activity and support access

Important actions preserve responsibility and history. Deeper Ironline support access is deliberate, purpose-limited, time-limited, and visible to the customer workspace rather than treated as routine browsing access.

Field continuity

Offline work with an explicit boundary

Supported field actions queue on the device and replay in capture order after a secure connection returns. Ironline does not present that queue as a complete offline copy of the workspace.

Providers

Optional systems fail visibly

Accounting, payments, communications, maps, calendars, and external workflows remain authorization-, configuration-, and proof-dependent. A saved connection alone is not treated as successful production operation.

Automation

Review, retry, and recovery controls

Rules can be validated and dry-run before activation. Failures can pause, retry, reconcile, and remain visible to managers instead of silently creating uncertain operating state.

Platform separation

Fail-closed high-risk paths

Provider events, subscription state, migration commits, support access, role changes, and outbound delivery use explicit validation paths. Unsupported or unverified state is rejected or held for review rather than assumed successful.

Buyer review areas

Bring the requirement that could stop adoption.

A Growth or Scale review should focus on the buyer’s actual access, field, financial, provider, migration, support, and policy requirements. Ironline will show the current behavior and identify anything that still needs a separate commitment or is not currently supported.

Identity and access

Authentication path, workspace membership, role permissions, invitation handling, support access, and administrative separation.

Customer and file boundaries

Customer links, private files, workspace ownership, exports, and the data a customer-facing route can access.

Financial and provider state

Payment evidence, refunds, disputes, accounting direction, provider authorization, webhook receipts, and reconciliation.

Mobile and offline behavior

Supported queued actions, device scope, synchronization order, conflict handling, and workflows that still require a live connection.

Migration and automation

Dry-run controls, supported commit scope, duplicate handling, retries, activity evidence, rule activation, pauses, and recovery.

Policies and support

Terms, privacy, cancellation, support channels, escalation expectations, and the current product or provider boundaries relevant to the buyer.

Published and reviewable

What a prospective customer can inspect now.

  • Workspace, role, customer-link, financial-state, offline, support-access, migration, and provider boundaries
  • Terms, Privacy, Cancellation, and Support policies
  • Current integration availability and activation model
  • Direct public support route and business phone number
  • A tailored review of the workflow and requirement before purchase

Not currently claimed

Requirements that need a direct answer before adoption.

  • SOC 2, ISO 27001, HIPAA, PCI merchant certification, FedRAMP, or another audit or regulatory status that has not been independently established
  • A contractual uptime percentage or 24/7 response commitment on a self-service plan
  • Complete offline access to every customer, communication, provider, or financial record
  • A live production integration based only on source code, a saved authorization, or a successful browser redirect
  • Single sign-on, automated user provisioning, or managed-device deployment unless separately confirmed for a Scale review

Direct accountability

Security questions reach the people responsible for the product.

A small vendor should not hide behind a sales maze. Describe the sensitive workflow, decision, provider, access pattern, or support expectation and ask for the exact current behavior before adoption.

Report a concern or review a requirement

Use the secure Support route for account-specific details. Do not place passwords, access tokens, payment credentials, or sensitive customer files in a public message.

Contact support

Review the requirement before trusting the claim.

Bring the access, field, financial, migration, provider, or support boundary that matters most. The review will show the current product behavior and name any gap directly.