Privacy Policy

InforceDesk is a customer relationship platform built for independent insurance agents. This policy explains what we collect when you visit our website or use the product, how we use it, who we share it with, and the rights you have over your information.

1. Our roles

InforceDesk acts in three different capacities depending on whose data is in question:

• As a controller, we decide how and why we process the personal information of our account holders (the agents and agencies who sign up for InforceDesk) and visitors to our website. That includes account credentials, billing details, and usage telemetry.
• As a processor, we handle the personal information that account holders upload or generate inside their workspace. This typically means details about leads, clients, appointments, notes, and documents. The account holder is the controller of that data; we store and process it on their behalf under the terms of our customer agreement.
• As a processor of an account holder's own Google data, when a member connects their personal Google Calendar through OAuth so the booking flow can avoid double-booking and route appointments to a free agent. The connected member is both the data subject and a controller of their own Google data; InforceDesk acts as a processor under their explicit, revocable consent. The specific treatment of that data is described in section 6 below.

If you are a lead or client of an InforceDesk account holder and you want to know what information they hold about you, please contact that account holder directly. We can help facilitate the request, but the account holder makes the final decision about access, correction, and deletion of records they entered.

2. Information we collect

2.1 Information you give us

• Account information: name, email address, password (stored as a salted scrypt hash), and the workspace name and slug you choose.
• Billing information: company name, billing address, the last four digits of the payment card, the card brand, and expiration. Full card numbers go to Stripe and never touch our servers. Stripe returns a customer ID and subscription status that we do store.
• Workspace settings and branding: logo URL, accent color, brand name, business hours, timezone, public domain, sender identity for outbound email, and integration credentials (encrypted at rest with AES-256-GCM).
• Customer-uploaded content: leads, clients, notes, documents, tasks, follow-ups, appointments, email templates, workflows, and any custom field values you create. You decide what to put here; we hold it for you.
• Support correspondence: messages you send us, including any attachments.
• Help-assistant conversations: questions you type into the in-app Help Assistant, along with the name of the screen you asked from. We send the question to Anthropic (section 5) to generate the answer, and we keep a transcript of both sides so our team can see where the assistant or the documentation falls short. Transcripts are deleted after 90 days (section 8). The assistant has no access to the records in your workspace, and nothing you type into it is attached to a lead or client — but the transcript is readable by our team, so don't paste anything into it you wouldn't put in a support ticket.

2.2 Information we collect automatically

• Session and device data: IP address, user agent, session token (HTTP-only cookie), and a CSRF token (HMAC-derived from the session). Sessions slide on activity and expire after 7 days of inactivity.
• Usage telemetry: pages visited, features used, counts of emails and SMS messages sent through the platform, document storage in bytes, and quota consumption per billing period. We use this to enforce plan limits and to debug.
• Audit log: workspace and member events such as invitations issued, role changes, integration credential updates, ownership transfers, and exports. The log records the actor, the event type, the IP, and the user agent.
• Tracking parameters when present: if a marketing URL includes gclid or utm_* parameters and the lead form forwards them, we store them on the lead record so the account holder can attribute the source. We do not place any client-side tracking pixels of our own on the lead-capture forms a customer hosts on their site.
• Marketing-site analytics: our own public pages (the marketing landing page, terms, privacy, security, signup, onboarding, and the Stripe success and trial-welcome pages) load Google Analytics 4, Google Ads (gtag.js), and the Meta (Facebook) Pixel so we can measure ad performance and signup conversion for InforceDesk's own marketing. These tags fire only on those public pages — never on the authenticated CRM pages where your customers' data lives. Section 5 lists the providers and section 7 lists the cookies they set.

2.3 Information from third parties

• Stripe reports invoice events, payment status, and subscription changes back to us via webhooks so the workspace status stays in sync.
• Twilio Lookup returns line-type and carrier information for phone numbers when an account holder asks us to validate one. Cached results are shared across workspaces because the answer is a property of the number, not the account.
• Google Calendar, when a member connects their account, returns calendar metadata, free/busy windows, and event details for the calendars they explicitly grant access to. Section 6 describes exactly which scopes we request, what we keep, and how to disconnect.

3. How we use information

We use the information described above to:

• Create and operate your account, authenticate you, and keep your session secure.
• Provide the CRM features you signed up for, including sending email and SMS on your behalf, booking appointments, running automated workflows, and storing the records you upload.
• Bill your subscription, retry failed payments, send dunning notices, and remind you when a trial is ending.
• Enforce plan quotas (monthly email, SMS, lead, and storage caps) and per-tenant rate limits so one busy workspace cannot starve another.
• Detect and prevent fraud, abuse, spam, and security incidents.
• Respond to support requests and notify you about service changes, outages, security advisories, and material updates to our terms or this policy.
• Improve the product. We look at aggregate usage to decide what to build next; we do not read the contents of your workspace for product analytics.
• Comply with legal obligations and respond to lawful requests from authorities.

4. Legal bases (GDPR)

If you are in the European Economic Area, the United Kingdom, or Switzerland, we rely on the following legal bases under the GDPR and UK GDPR:

• Contract: to provide the service you signed up for, including billing.
• Legitimate interests: to secure the platform, to enforce our terms, to detect fraud, and to send service-related communications.
• Consent: for optional marketing emails from us. You can withdraw consent at any time by clicking the unsubscribe link in any marketing message.
• Legal obligation: to retain certain records (for example, billing records) for the period required by tax and accounting law.

5. Sharing and subprocessors

We do not sell personal information, and we do not share it for cross-context behavioral advertising. We do share data with the following service providers (subprocessors) who help us run the platform. Each one is bound by a written contract that limits how they may use the data.

We may also disclose information when we believe in good faith that disclosure is required by law, by a court order, or by a government request; when needed to enforce our terms; when needed to protect the rights, property, or safety of InforceDesk, our customers, or the public; or in connection with a merger, acquisition, financing, or sale of all or part of our business. In a corporate transaction, we will require the recipient to honor the commitments in this policy or notify affected individuals of any material change.

6. Google API user data

When a member of an InforceDesk workspace connects their personal Google account through the OAuth flow at /crm/settings/calendar, InforceDesk receives data covered by the Google API Services User Data Policy, including the Limited Use requirements. This section describes that handling specifically.

6.1 Limited Use compliance

InforceDesk's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

In practical terms, InforceDesk uses Google Calendar data only to provide and improve user-facing features that are visible to the connected member and the workspace operator. We do not use it to serve advertisements; we do not transfer it to third parties except as needed to provide the booking feature and where compelled by law; we do not allow humans to read it except where the connected member explicitly asks for support, where it is necessary for security investigations or to comply with applicable law, or where the data has been aggregated and anonymized so it cannot be used to identify any individual user.

6.2 Scopes we request

When a member starts the connect flow, Google asks them to approve the following scopes. Each scope is requested only because the booking feature cannot work without it; we do not request any broader scope to "future-proof" the integration.

• https://www.googleapis.com/auth/calendar.events — read, create, update, and delete events on the calendars the member chooses to grant. Used to (a) read the member's existing events so the booking page and the in-app calendar view can show them, and (b) create a new event on the member's primary calendar when an appointment is booked, then update or delete that event when the appointment is rescheduled or cancelled. We do not request the broader calendar scope, which would also expose calendar settings and access-control changes that we do not need.
• https://www.googleapis.com/auth/calendar.events.freebusy — query free/busy windows so the public booking page does not offer time slots that conflict with the member's existing events. This is a narrowly scoped permission that only returns busy intervals (start and end timestamps); it does not expose event titles, attendees, or descriptions. We chose it instead of the broader calendar.readonly scope, which would have granted read access to every event on every calendar the member can see.
• https://www.googleapis.com/auth/calendar.calendarlist.readonly — list the calendars the member can see, so the in-app picker can show calendar names instead of asking the member to paste calendar IDs.
• openid and email — read the connected Google account's primary email address so the in-app UI can show "Connected as [email protected]" and so workspace admins can tell which member's calendar is which.

6.3 What we receive, what we keep, and what we never store

What we keep on our servers:

• The Google email address of the connected account.
• The OAuth refresh token, encrypted at rest with AES-256-GCM. The encryption key is bound to the workspace, the user, and the provider as additional authenticated data, so a stolen ciphertext copied between rows in the database would not decrypt.
• A short-lived access token (typically one hour) cached only until expiry, encrypted with the same scheme. The access token is what we present to Google when we make a request; we never expose it to the browser.
• The calendar IDs the member picked: one primary write target plus zero or more "availability" calendars to read free/busy from.
• The Google event ID of any event we create on behalf of a booking, so cancellation and reschedule can find the right event.

What we read at request time but do not persist:

• Free/busy windows from the calendars the member granted. We query them in real time to decide which time slots to offer on the booking page; the response is used immediately and discarded.
• Event titles, descriptions, locations, and attendee lists when InforceDesk reads or writes a single event on the member's behalf. We do not copy other events from the member's calendar into our database; our only persisted record of any event is the one we created ourselves, and even then we keep just the Google event ID, not the body.
• The list of calendar names the member can see, fetched when the picker page renders so they can choose which calendar to use.

In short: free/busy and event content cross our servers in transit but are not written to our database. The only Google-derived fields we persist are credentials (encrypted), the connected email, the chosen calendar IDs, and event IDs of bookings we created.

6.4 What we do not do

• We do not sell, rent, or license Google Calendar data.
• We do not use Google Calendar data to serve advertisements anywhere — not in InforceDesk, not on our marketing site, not through retargeting networks.
• We do not use Google Calendar data to train, test, or fine-tune generalized machine-learning models, including large language models. The booking feature does not call out to any AI service with calendar content.
• We do not transfer Google Calendar data to third parties except as required to provide the booking feature (for example, our hosting provider stores the encrypted credentials at rest like every other database row), or as compelled by law.
• We do not allow humans on our team to read calendar event content. The data is processed by automated systems on the request path. The narrow exceptions listed in section 6.1 (the connected member's own support requests, lawful security investigations, or aggregated anonymized analysis) are the only times a human at InforceDesk would touch this data.

6.5 How to revoke access

You can disconnect at any time, in either of two ways:

• Inside InforceDesk: visit /crm/settings/calendar and click Disconnect Google Calendar. We immediately revoke the refresh token at Google and delete the local row, including the encrypted credentials and the picker selections.
• From your Google account: visit myaccount.google.com/permissions, find InforceDesk in the list of apps with access to your account, and remove it. Google will invalidate our refresh token. The next time our system tries to use the token it will receive an error and stop; no further calendar reads or writes will succeed.

Disconnecting is independent per member. One agent disconnecting does not affect their teammates. Disconnecting also does not delete events that InforceDesk previously created on the member's calendar — those events stay on the calendar exactly as they would for any normal Google Calendar event the user no longer owns through a third-party app. The member can delete those events directly in Google Calendar if they wish.

6.6 Retention

We retain encrypted credentials and picker selections only for as long as the connection is active. When the member disconnects (or when the workspace is deleted and the 30-day soft-delete grace expires), the database row containing the credentials, calendar IDs, and connected email is removed by an automated sweep. Backup retention follows the same 35-day window described in section 8.

Free/busy responses and event payloads are not retained at all — we discard them as soon as the booking decision is made.

7. Cookies and similar technologies

We use a small number of strictly necessary cookies inside the authenticated app, plus advertising and analytics cookies on our own public marketing pages. The authenticated CRM where your customer data lives does not load any advertising or analytics tags.

Strictly necessary (set by us, inside the app):

• crm_token — HTTP-only session cookie. Identifies your authenticated session. Required for the app to work.
• crm_csrf — readable CSRF token, derived by HMAC from your session token. Required to submit forms in the app.

Analytics and advertising (set by third parties, only on our public marketing pages):

• _ga, _ga_*, _gid, _gcl_* — Google Analytics 4 and Google Ads. Measure visits and signup conversion. Set by googletagmanager.com when the gtag.js library loads.
• _fbp, _fbc — Meta (Facebook) Pixel. Measure visits and signup conversion for Facebook and Instagram ad campaigns. Set by connect.facebook.net when the pixel loads.

These tags fire on the marketing landing page, terms, privacy, security, signup, onboarding, and on the Stripe success and trial-welcome pages. They never fire on the authenticated CRM. None of your tenant data (leads, clients, documents, notes, messages) is sent to Google or Meta.

Account holders who connect Google Analytics 4 or Google Ads to their own workspace are responsible for disclosing those cookies on their own marketing site and for obtaining any consent that local law requires. Those per-workspace integrations are separate from the tags we run on InforceDesk's own marketing site.

8. Data retention

• Account and workspace data: kept for as long as your account is active. After you delete a workspace, we hold a recoverable copy for 30 days. After that window, the workspace and every record under it are removed by an automated sweep, including leads, clients, notes, documents, workflows, audit log entries, and integration credentials.
• Billing records: retained for the period required by tax and accounting law in our jurisdiction (typically seven years), even after account closure.
• Backups: deleted records may persist in encrypted backups for up to 35 days before they age out of the backup window.
• Email and SMS opt-outs: retained indefinitely so we can honor unsubscribe requests and TCPA opt-outs across the platform, even after the original account holder is gone.
• Audit log: retained for the life of the workspace; cascaded with the workspace when it is permanently deleted.
• Help-assistant transcripts: removed by an automated sweep after 90 days. We can also delete individual conversations sooner on request.

9. Security

We take reasonable and appropriate technical and organizational measures to protect personal information. These include:

• TLS 1.2+ for data in transit between your browser and our servers.
• Passwords stored as salted scrypt hashes; never in cleartext.
• Integration credentials (Resend API keys, Twilio auth tokens, Google service-account keys, Stripe keys) encrypted at rest with AES-256-GCM, with the encryption key bound to the workspace and integration type as additional authenticated data.
• API keys stored only as SHA-256 hashes; the raw value is shown to the operator exactly once at creation.
• HMAC-signed CSRF tokens, content security policy headers, parameterized SQL throughout, server-side input validation, SSRF blocklists for outbound webhooks, and per-IP and per-tenant rate limiting.
• Per-row workspace scoping enforced at the database layer with NOT NULL workspace foreign keys, plus a build-time audit script that flags any SQL touching a tenant table without a workspace filter.
• Soft-delete with a 30-day grace window before destructive cascade.

No system is perfectly secure. If we discover a breach that affects your personal information, we will notify you and the appropriate regulators within the timeframe required by applicable law.

10. International data transfers

Our primary infrastructure is located in the United States, and several of our subprocessors are based in the United States. If you access the service from outside the United States, your information will be transferred to, stored in, and processed in the United States and other countries where we or our subprocessors operate. Where required, we rely on the European Commission's Standard Contractual Clauses or the UK International Data Transfer Addendum to authorize cross-border transfers.

11. Your privacy rights

Depending on where you live, you may have some or all of the following rights regarding your personal information:

• Access: ask for a copy of the personal information we hold about you.
• Correction: ask us to correct information that is wrong or incomplete.
• Deletion: ask us to delete personal information we hold about you, subject to legal retention obligations.
• Portability: ask for a copy of your data in a structured, commonly used, machine-readable format. Account holders can use the built-in workspace export at /crm/settings/export to download a zip of every workspace-scoped table plus original document files.
• Restriction or objection: ask us to limit or stop certain processing.
• Withdraw consent: where we rely on consent, you can withdraw it without affecting processing that already happened.
• Lodge a complaint: with your local data protection authority.

To exercise any of these rights, email [email protected]. We will respond within 30 days, or sooner if local law requires it. We may need to verify your identity before acting on a request. If you are a lead or client whose record was uploaded by an InforceDesk account holder, please contact that account holder directly. We will assist them in fulfilling your request, but we cannot make decisions about records they control.

12. California residents (CCPA / CPRA)

If you live in California, the California Consumer Privacy Act, as amended by the CPRA, gives you additional rights:

• The right to know the categories and specific pieces of personal information we have collected about you, the sources, the business purposes, and the categories of recipients we shared it with.
• The right to delete personal information we collected from you, subject to legal exceptions.
• The right to correct inaccurate personal information.
• The right to limit the use and disclosure of sensitive personal information.
• The right not to be discriminated against for exercising any of these rights.

We do not sell personal information, and we do not share it for cross-context behavioral advertising as those terms are defined under California law. We have not done so in the past twelve months.

To exercise these rights, email [email protected] with the words "California Privacy Request" in the subject line. You may also designate an authorized agent to make a request on your behalf; we will need written proof of the agent's authority and may still need to verify your identity directly.

13. Marketing communications

Messages that account holders send to their leads and clients through InforceDesk go out under the account holder's sender identity, on behalf of the account holder, and at the account holder's direction. The account holder is responsible for compliance with the CAN-SPAM Act, the Telephone Consumer Protection Act (TCPA), and any other law that governs marketing email or SMS in the recipient's jurisdiction.

Our platform helps account holders meet those obligations by appending unsubscribe footers to marketing email, by separating SMS consent from email consent, by honoring STOP keywords on inbound SMS, and by enforcing TCPA quiet hours on outbound SMS. The legal duty still sits with the account holder.

Messages that InforceDesk sends to you directly (account confirmations, billing notices, security alerts, password resets) are transactional and necessary to operate your account. You cannot opt out of these while you have an active account. Optional marketing email from InforceDesk includes an unsubscribe link that you can use at any time.

14. Children's privacy

InforceDesk is not directed to children under 16 and we do not knowingly collect personal information from anyone under 16. If you believe a child has provided us with personal information, contact us at [email protected] and we will delete the record.

15. Changes to this policy

We may update this policy from time to time. When we make a material change, we will revise the "Last updated" date at the top of the page and, depending on the nature of the change, notify you by email or through an in-app notice before the change takes effect. Continued use of the service after the effective date constitutes acceptance of the updated policy.

16. Contact us

Questions about this policy or about how we handle your personal information:

If you live in the European Economic Area or the United Kingdom and you are not satisfied with our response, you have the right to lodge a complaint with your local data protection authority.