Every field service app you use stores your customers' names, home addresses, phone numbers, and payment information. If that data is mishandled, you are the one your customers hold responsible—not the software company.
When you manage jobs in a field service app, you are trusting that software with personally identifiable information (PII)—your customers' full names, home and business addresses, phone numbers, email addresses, and in many cases their payment details.
Under data protection laws and common-law negligence standards, businesses that collect customer PII have a duty of care to protect it. If a software tool you chose suffers a breach or mishandles data, your customers will look to your company—not a faceless SaaS vendor—for answers.
Before you trust any web application with your customers' personal information, demand to know exactly how they protect it. If they can't answer clearly, that is your answer.
These are not premium features. These are baseline requirements for handling your customers' data responsibly.
Passwords must be cryptographically hashed—never stored in readable form. If a database is compromised, properly hashed passwords are designed to be irreversible.
Any third-party tokens (QuickBooks, payment processors, etc.) stored in the database must be encrypted at rest using strong, authenticated encryption.
Every page, every API call, every data transfer must be encrypted in transit. No exceptions. If any part of the app loads over plain HTTP, walk away.
HTTP security headers (HSTS, Content-Type protection, XSS filters, referrer policies) prevent common web attacks. They should be enforced on every response.
Weak passwords are the #1 way accounts get compromised. The software should enforce minimum length, complexity, and reject common patterns.
Not every user needs access to everything. Technicians, admins, and owners should each see only what they need—enforced at the server level, not just the UI.
Your data must be completely walled off from other companies using the same software. Every database query should be scoped to your organization only.
Login pages and APIs must be protected against automated attacks. Without rate limiting, attackers can guess passwords thousands of times per minute.
Every API endpoint must verify the caller's session token and confirm their identity, role, and organization membership before processing any request.
Every security-sensitive action—logins, role changes, failed access attempts—must be logged with timestamps, IP addresses, and actor details for accountability.
We don't make vague promises. Here is exactly what we do and how we do it.
Every user password is processed through bcrypt with 12 adaptive cost rounds before it is stored. Hashed passwords are designed to be irreversible—they cannot be decrypted or read back in plain text, even by our team.
All traffic between your browser and our servers is encrypted using TLS (Transport Layer Security). We enforce HTTPS across the entire application—every page, every API call, every data transfer. Plain HTTP connections are automatically redirected.
We enforce strong password requirements at signup and password change: minimum 8 characters, requiring uppercase, lowercase, numbers, and special characters. Common passwords and dictionary patterns are blocked before they are ever accepted. Real-time strength feedback guides users to create strong passwords.
Users are assigned roles with distinct permissions: Admin, Manager, Foreman, Sales Rep, Crew, Contractor, Vendor, and Bookkeeper. Access control is enforced on every API route at the server level—not just in the interface. A crew member cannot reach admin reports, billing, or team management endpoints regardless of how the request is constructed.
Every database query is scoped to your organization's unique identifier through Prisma middleware. The system is designed so that one company's users cannot access another company's customers, jobs, estimates, or financial data—this isolation is enforced at the data layer, not just the interface.
We enforce strict request-rate limits across authentication endpoints: 10 login attempts per 15 minutes per IP, 8 per email, 5 signup attempts per hour, and 5 password reset requests per 15 minutes. Automated attacks and brute-force attempts are throttled well before they can do damage.
Every API endpoint verifies the caller's session token and confirms their identity, role, and organization membership before processing any request. Unauthenticated or unauthorized requests are rejected immediately. Sessions expire after 8 hours with 15-minute refresh cycles.
Every security-sensitive action is recorded in a dedicated audit log: login successes and failures, signups, password resets, role changes, account activations and deactivations, and user deletions. Each entry captures the IP address, user agent, severity level, and full context—providing complete accountability and forensic capability.
All user inputs across authentication endpoints are sanitized against HTML injection, cross-site scripting (XSS), and other injection attacks. Email addresses are normalized, special characters are escaped, and malicious payloads are stripped before processing.
Sessions are configured with industry-standard security: 8-hour maximum lifetime, 15-minute token refresh intervals, and secure cookie attributes. This minimizes the window of opportunity for session hijacking while keeping the user experience seamless.
We built this page not just to show you what 2Work does—but to give you a checklist to hold every software vendor accountable. Your customers trust you with their personal information. That trust is not something to gamble with a tool that can't explain how it protects their data.
If you're currently on another FSM platform, ask them one question: "How do you protect my customers' data?" If the answer isn't clear and specific, you owe it to your customers to find out why.