iUseFlow — dispatch and field-service platform for Swiss SMEs · Version 2026-10-18
This statement applies to the iUseFlow platform (web application and technician
app) and to its use by companies ("customers" or "company") and their employees
("users").
1. Applicable law
The Swiss Federal Act on Data Protection (FADP) and its ordinance (DPO) govern.
Where foreign data protection law additionally applies in an individual case,
processing follows the applicable law. We deliberately make no blanket
compliance claim in respect of foreign legal systems here.
2. Controller — two separate roles
The roles are not the same for all data. This is not a formality: it determines
whom you need to approach.
Job, assignment and workforce data: the controller is the customer
company that uses iUseFlow to dispatch its jobs. iUseFlow processes this data as
a processor under Art. 9 FADP, on instructions.
Account, contract, billing, security, support and website data: here
iUseFlow determines the purposes and means itself and is to that extent a
controller in its own right — for the contract with the company, billing,
abuse prevention and the operation of this website.
3. What data we process
Account and contact data: name, username, e-mail address, telephone
number.
Location data: postcode/address of jobs for scheduling — in the
current V1 a typed job/customer address is used only for a local zone
approximation; the Google Maps routes are disabled (section 6). Capturing
the device location of individual staff
members (GPS coordinates on a status update, photo upload, warehouse
scan, customer link, native status update, or a GPS form field) is
disabled for new captures: none of these actions produces a new
coordinate today, regardless of any location permission granted.
Coordinates from before this was disabled may still be stored in job,
status, photo, scan or form records; they are no longer shown in any
output of the platform until a cleanup of this legacy data has been
decided (section 12). The only exception is the access response to the
person concerned (section 15). There is no background location
tracking.
Job data: assignments, time tracking, absences, photos/documents,
signatures and completion records created in the course of a job.
Place of work and calendar: so that the office and the app show the applicable public holidays, the company records its place of work (canton, optionally municipality). If a person works in another canton, the company can record their own place of work; only the person and authorised people in the company see this, not their colleagues. Optionally, the company chooses a region as its school holiday profile; school holidays are for orientation only and never create an absence. No data about children is collected. Public holiday and school holiday data come from official sources (SECO, cantons) and are kept in iUseFlow; you only leave iUseFlow when you open a link to a source.
Profile photo (optional): staff can add a profile photo in the app, or the company adds it in the office. It serves only for recognition within the company: it is visible to colleagues, dispatch and the office of the same company, never to customers – it does not appear on the "Your appointment" page, in the customer portal, in PDFs, in emails or in the copy of the job report. The person can see whether they added it themselves or the office did, and can remove it themselves at any time. On upload, iUseFlow removes location and camera details, straightens the image and reduces it (512 pixels at most, JPEG); only this image is stored. Photos in HEIC format are not accepted.
Fleet data: if a company manages its fleet in iUseFlow, we store for each vehicle the number plate, make/model and vehicle type, the regular driver, the vehicle assignment per day, service and MFK (roadworthiness test) dates, the equipment on the vehicle and with people, and damage reports that name a vehicle. Because this information is linked to a person, we treat it as personal data. It serves job planning, maintenance and reminders of service and MFK dates. It is visible to the office and dispatch; a member of staff sees their own vehicle and their own vehicle assignments and, for a shared vehicle, only the name of the other person. iUseFlow records no vehicle location, no telematics, no trip log and no kilometres driven. iUseFlow shows due service and MFK dates to the people who may edit the fleet; if the company has set up e-mail sending, they receive at most one e-mail per vehicle and date, which names neither the vehicle nor a person.
Company information to its customers: if a company switches on customer
information, its customers receive e-mails about the appointment and the job status
(appointment confirmation, appointment change, on the way, on site, completed) and, on
request, appointment proposals. The messages contain the company name, the job number,
the date, the time window, an approximate arrival time and a personal link. They name no
employees and no location. The approximate arrival time is given voluntarily by the
technician when setting off ("in about 20 minutes"). It is not based on any location
tracking and is deleted as soon as the work on site starts, is completed or is
cancelled. If customers choose "None of these suits me" in an appointment proposal, they
can send a short comment to the company.
Copy of the job report for customers: after completion, the company can make the sealed job report available to its customers as a personal link – by e-mail (without attachment) or by the technician passing on the link via WhatsApp, SMS or the share function of their own phone. Only the link passes through the chosen service; the PDF stays in iUseFlow. So that the company can see what happened to the copy, we only store points in time: link ready, e-mail requested, accepted by the sending service or failed, handed to an app (with the channel) and the first time the PDF was opened via the link or the portal. "Handed over" does not mean "received", and "accepted" does not mean "read". Requests from preview services of messengers and search engines are not counted. We do not store any IP address or any details about the customer’s device or browser. If the technician enters an e-mail address other than the one in the customer record, it is stored for sending and shown only in shortened form in the log.
Job duration: from a person’s own status updates on a job (on the way, on site, done), iUseFlow calculates the travel and working time per visit; no additional timestamps are stored for this. The person sees their own time and can correct it with a reason (status reported late, break, other) and an optional short text; the correction is stored as a separate entry and the original status updates remain unchanged. Only the person themselves and those authorised for the company’s time accounts can correct; only the latter see the times of the individual people on a job. For planning, iUseFlow uses durations only aggregated per job type across the whole company (median and range, only from five completed jobs by at least two different people). There is no evaluation per person, no comparison between people and no league table.
Crew confirmation: if another person worked on a job, the scheduled person can name them. The named person sees the entry in their app (job number, date, time window, postcode and who named them) and confirms or declines it themselves; only after their confirmation do they count as crew for that job and receive the job time. A pending or declined entry stays visible to the office as a note and never becomes time of the named person.
Delay report: if the technician reports a delay, we store the new approximate arrival time, who reported it and when, and optionally an internal reason (previous job, traffic, material, other). On the “Your appointment” page, customers only see “New estimated arrival approx. HH:MM” – and only if the company has switched on the “on the way” customer information; they never see the reason or the person who reported it. While on the way, the new time replaces the arrival time given when setting off. No e-mail and no SMS is sent for a delay. The report applies until arrival on site; afterwards it remains only in the job history.
Short feedback and “Good to know”: after a job, the scheduled person can optionally record short facts about the site: how many people were needed, parking, lift, access and a short note (“Good to know”, at most 280 characters, labelled “Facts about the site only – no assessment of people”). There is no field that assesses customers or staff. “Skip” is always possible and is not asked again for that job. The information belongs to the site (customer and address) and appears, with the date and the name of the person who recorded it, on the next job at the same site for the office, dispatch and the scheduled people; it can lead to a “2 people” hint, which is only a hint and assigns nobody automatically. The office can edit or delete an entry; both are logged. The information is part of the customer’s right of access (Art. 25 FADP).
“Who is away” (team view): in the app, colleagues in the same branch – without a branch, those of the whole company – see who is absent on which days: name, profile photo (if one exists), period and whether it is a half day. They never see the type of absence, a reason or a comment; only people who decide on absences see pending requests. When requesting leave, the app shows only the number of people already absent on a day. The company can switch the team view off in the settings; then only the people who decide on absences still see it.
Clocking without a connection: if a person clocks in or out, or starts or ends a break, without a connection, the app stores the moment of the tap and sends it as soon as the connection is back. The server accepts it only on the same day, at most three hours back and never in the future; otherwise the entry has to be added as a time correction. We store the moment the server received it separately in the log. No location is recorded.
Shift schedule and confirmed planned time: if the company plans with a shift schedule, we store for each shift the date, start, end, break, role, zone, branch and a note, and who created, published or cancelled it (with a reason). In the app a person sees only their own published shifts and the open shifts of their branch, without names; they do not see drafts or their colleagues’ shifts. When their schedule is published or changed or a shift is cancelled, they receive a message inside iUseFlow – no push notification and no email. After a shift ends, they can confirm the planned time as working time with one tap; nothing is confirmed without their tap, existing clock entries are not overwritten, and a deviation is added as a time correction. We store the confirmed times and the moment of confirmation; the confirmation is logged. While planning, iUseFlow shows the office notices with the legal article (approved absence, public holiday, company closure, rest period, break, weekly maximum, publication notice period); they rate nobody and block nothing.
Time inbox, daily list and timesheet: if staff record their own time, iUseFlow shows the office in one place what needs a look: correction requests (the requested times next to the clocked ones), absence requests with the number of people already absent on those days, clock entries that are still open, planned shifts without confirmation, and notices on the Employment Act (break under Art. 15, rest under Art. 15a and weekly maximum under Art. 9 ArG, 45 or 50 hours as chosen). Notices, not ratings: they state the measured figure and the legal article, there is no figure per person and no comparison of people, and they block nothing – not even clocking in. The office can mark a notice as «noted»; who and when is logged, and the notice itself is not deleted. Nobody decides their own request; only if there is no other authorised person in the company is the decision recorded as «decided by oneself». If the office adds a time, for example the end of an open clock entry, it must give a reason; the person sees the entry with who and why. The daily list (everyone on one day with in, out, breaks, total, source of the time, planned shift and absence) is visible only to those who may see other people’s time accounts. Each person can download their own timesheet (PDF or CSV per person and month), the office for people in its scope; several people at once require an additional confirmation. Timesheets are generated anew on each request and not stored; every request is logged.
Still clocked in: if a person has been clocked in since an earlier day or for longer than the time set by the company (default 10 hours), they receive one message per day within iUseFlow – no push notification and no email. An open clock entry is never ended automatically: the person clocks out or adds the time, or the office adds it with a reason.
Scanning in the app: the technician app can scan QR codes and barcodes (material, jobs, service stickers on devices, clock-in QR). Permission to use the camera is asked only at the first scan, and the camera is used only while the scanner is open; no image is stored or transmitted – only the code read is sent to iUseFlow to resolve it. A code grants nothing: what the person sees or books afterwards depends on their rights.
Clocking via QR on site: the company can put up clock-in QR posters for a place (company, branch or a named place). When a person scans such a poster, they clock in or out; we store the name of the place as a fact on the clock entry, who clocked and when – no GPS, no coordinate and no location history. Without a connection, the moment of the tap counts as for ordinary clocking. The company can switch on «Clock in by QR only» as a hint; nothing is blocked by it.
Material, picking and job sheet: every material booking (for example picked, used or returned) is recorded in the stock journal with the item, quantity, place, job, time and the person who booked it (name and role). The picking list shows per person and day the reserved material of their jobs with store and bin; the job sheet of a job contains the job, time window, customer, site, on-site contact, «Good to know» without names, the material and a QR of the job. Stock bookings are facts about goods, not a rating of people; the person can request information about the bookings that concern them (Art. 25 FADP).
Day planning by area and map: for dispatch, iUseFlow groups the jobs of a day by area and suggests per area a suitable person and a visiting order. iUseFlow determines the location of a job locally from the postcode and swisstopo’s official table of localities, or from a pin the office sets by hand; job and customer addresses are not transmitted to anyone for this. Your browser loads map tiles directly from swisstopo (Swiss Confederation); swisstopo sees the IP address and the map section, no job or customer data. The company can switch off «Show map»; then no map tiles are loaded. There is no live position and no GPS of employees: the starting point of a suggestion is the base (branch or company). A suggestion rates nobody and assigns nothing; a job is assigned only when dispatch confirms.
Access and arrival: for a site, the assigned employees and the office can record facts (parking, lift, access, narrow access, van height, access window, permit needed) and a photo of the site, for example of the access; metadata such as GPS coordinates are removed from the photo before it is stored, and people should not be photographed. The company can maintain access zones (for example an old town with access times); they appear as a hint, never as a block. These facts belong to the site, are not a rating of people and are kept like «Good to know»; the office can correct or delete them, and the photo is deleted with the entry.
iUseFlow Zeit without dispatch: a company can use iUseFlow only for working time, absences and rosters («Zeit only»); this choice is stored with the company at sign-up. Billing is per active person with time recording; for this iUseFlow counts the active people, office accounts do not count.
Wage export: roles with the export right (by default the owner and HR) can download a CSV file per month for payroll: target, actual, balance, extra hours, time above the maximum working time, night and Sunday work, and vacation and absence days per person. Health-related absences appear in it only as «absence without type». The file is generated on request, not stored in iUseFlow and not sent; every download is logged and requires a fresh confirmation with the password.
Inspection package for the labour inspectorate: the same roles can download the records under Art. 73 ArGV 1 for a month or period as a ZIP file: start, end and breaks per day and person, weekly totals, notices on the Labour Act with the article, absences and the company’s working-time rules. Notices are not a rating of people, and the package is not a legal assessment; it is generated on request, not stored and not sent, and every download is logged.
Team chat: employees and the office can exchange work messages in iUseFlow: in the thread of a job and in channels for a team, a branch or the whole company. There are no private one-to-one chats. We store the text (at most 2000 characters), an optional photo (metadata such as GPS coordinates are removed before storage), the channel, the author and the times of sending, editing and removal. The thread of a job is read by everyone allowed to read the job (the assigned people and the office with job rights); a team channel is read only by its members, «Whole company» by all active accounts. The office reads no channel it is not a member of – neither through the company data export nor through a support access. There are no read receipts for others, no «last online» display, no evaluation per person and no keyword monitoring; iUseFlow only remembers for you how far you have read, to show you the number of unread messages. You can edit or remove your message for 15 minutes; after that it stays. The moderation of a channel can remove a message with a reason; this is logged without the message text. Of a removed message only the note «Message removed» remains. The app shows new messages as a number; no push notifications or e-mails are sent for this. The app stores the most recently loaded messages on the device and deletes them at logout. Every member can report someone else’s message with a reason; the report is seen by the channel’s moderation (if nobody moderates the channel, people allowed to change the company settings see only the reported message and its two neighbours, logged), the reported person is not told who reported it, and the report is deleted with the message or 12 months after it was handled. Your own messages are part of the right of access under Art. 25 FADP.
Defects: when a technician finds a defect on a job, we store the label (from the company’s defect catalogue or as free text), a description, the location or component, severity, status, photos before and after the fix, the job and – where available – the asset, the person who recorded it, the responsible person set by the office, a due date and a history of who changed what and when. A defect describes a thing; there is no field for who caused it, fault or liability. Defects are visible to the office and to the people assigned to the job; anyone assigned to a job on the same asset sees the asset’s open defects with label, severity, state, date and job number. Customers see a defect only if it is expressly marked "Visible to customer": label, severity and state then appear on the proof of delivery or service report (also in the customer portal), and open defects may be named in the notice shown before signing – never with the description, photos or names. For a defect rated "Danger", the office receives a notice inside iUseFlow that states only the job number.
Damage reports: when someone reports damage (at the customer, to a vehicle or to a tool), we store what happened, photos, the damaged object, the time, whether the customer was informed, any cost estimate, the reporting person and who in the office acknowledged receipt and who closed the case, each with the time. Damage reports are visible to the office and to the people assigned to the job; they do not appear on documents for customers. The office receives a notice inside iUseFlow; it states only the job number and the type of damage, never what happened. If a report has still not been acknowledged after 24 hours, iUseFlow reminds the office once, again stating only the job number. No push notifications or e-mails are sent for this. "Acknowledged" only means that the office has seen the report; it is not a statement about fault or liability.
People affected (damage report): a damage report can state that people were affected, and which group (staff, customers, third parties). There is no field for the names of affected people or for details of injuries or health; such details do not belong in the description of what happened either. This information is visible only to the reporting person and to roles that the company has given the right for health documents (by default owner and HR). These roles see an overview of the reports concerned without the description of what happened; every retrieval of this overview is logged. The company’s full data export, which only the owner can trigger, also contains this information. In case of injury, the company’s emergency and reporting procedure applies; iUseFlow is not an alarm system.
Sensitive personal data: new absence requests accept no health type,
medical attachment, reason or comment. On 28 August 2026 the verified legacy
health data was deleted from active primary storage. The remediation left no
active primary row and no active blob reference; section 12 describes the
remaining backup boundary.
Configurable forms: a company can configure text, long-text, upload or
signature fields for operational purposes. Unstructured fields explicitly
labelled as medical or absence-related are technically rejected. A neutrally
labelled field nevertheless remains user content; health information must not be
entered there. The company determines and is responsible for the purpose and
permitted content of its forms.
Billing and customer data: customer name, address, invoice amounts
(entered by the company).
Technical data: device information, IP address, timestamps, error logs
(to secure access and for support).
4. Purposes of processing
Planning and assigning jobs to technicians and staff
Time tracking, absence management and payroll-relevant evaluations
Communication with customers (invoices, quotes, status reports)
Local zone approximation for scheduling (section 6)
Performing the contract with, and billing, the company
Operation, security, error correction and further development of the platform
5. Recipients
We do not sell data. The technician app contains no advertising and no
third-party analytics or tracking services. Fonts are served from our own servers;
no connection is made to Google Fonts.
For the current V1 scope, a server-enforced allowlist determines whether
a provider route is reachable. Stored credentials or earlier account connections
do not open a technically disabled route.
Recipient
Role
Purpose
Data concerned
Contracting party / country
Exoscale (Akenes SA)
processor
Operation of the application, database and file storage since 16 September 2026; nightly database backups
all data actively processed in the platform; backups may contain time-limited remnants of data already deleted
Switzerland (Zurich, zone CH-DK-2; data-centre operator Equinix). Contracting party: Akenes SA, Boulevard de Grancy 19A, 1006 Lausanne, Switzerland (CHE-423.524.322). The Data Processing Addendum is governed by Swiss law (jurisdiction: canton of Vaud) and was accepted in the legal section of the account before provisioning (as at 16 September 2026); it permits transfers only within Switzerland, the EU/EEA or countries with adequate data protection. Sub-processor Aiven Oy (Helsinki, Finland) for the orchestration of the managed database; the database data itself is stored in zone CH-DK-2
Railway (former)
former processor
Operation of the platform until 16 September 2026; on 28 September 2026 the three former production services were removed and each of the three original production volumes received one supported, one-time wipe (no PITR card remains afterward, no proven rollback); the current Exoscale production path transmits no new data to these former Railway production services
metadata for 18 historical backups is still returned by the provider API; no final statement is made about remaining content, recoverability or provider-side deletion
United States, region US West (sfo, historical). The account-specific DPA was executed by both parties with effect from 27 August 2026 and remains relevant for the earlier processing and any remaining storage; it is not the contract for the current Exoscale operation. Its scope for employee data remains subject to separate assessment
Google Maps Platform (server-side)
provider route technically disabled for V1
no active processing; the platform uses a local zone approximation
no transmission to Google through this route
must be reassessed before activation
Google Maps Platform (in the browser)
provider route technically disabled for V1
no address completion or Google map at present
no transmission of an address, IP address or staff coordinate through this route
must be reassessed before activation
Sign-in with Google
provider route technically disabled for V1
no Google sign-in at present; historical links remain only as unavailable account information
no new transmission through this route
must be reassessed before activation; sign-in and recovery use email/username and password
Sign-in with Microsoft
provider route technically disabled for V1
no Microsoft sign-in at present
no transmission through this route
must be reassessed before activation
Sign-in with Apple
provider route technically disabled for V1
no Apple sign-in at present; historical links remain only as unavailable account information
no new transmission through this route
must be reassessed before activation; sign-in and recovery use email/username and password
Microsoft 365 / Graph
provider route technically disabled for V1
no e-mail read/send or calendar synchronisation at present
no transmission through this route; historical connections and tokens can still be disconnected and cleaned up
account region and permissions must be reassessed before activation
Anthropic (Claude API)
provider route technically closed
no active processing at present
no platform transmission — see section 11
must be reassessed before activation
Expo, and Apple or Google as delivery/update service
provider route technically disabled for V1
no push registration/delivery or EAS/OTA runtime update at present
no new device token, message or update-request transmission; deletion of historical tokens remains available
must be reassessed before activation
Stripe
independent controller for payment data — under its own terms Stripe determines purposes and means itself
Subscription, payment and billing of the company
payment and billing details of the company
contracting party outside North and South America: Stripe Payments Europe, Limited (Ireland); transfer to Stripe, LLC, United States
Sentry
provider route technically disabled for V1
no external error telemetry at present
no transmission; local platform logs remain available
must be reassessed before activation
Resend
processor
Sending fixed platform notices where no own mail server is configured
recipient address, fixed subject/notice text and technical delivery metadata; no attachments, free text or medical information
primary processing in the United States; the DPA provides for standard contractual clauses with Swiss adaptation. There is no Swiss DPF certification
Regarding Sentry: the provider route is technically disabled for the
current V1 scope. The closed allowlist remains in code as an additional dormant
control; setting a DSN does not open the route.
6. Transmission to Google from the browser
The server-side and browser-side Google Maps routes are technically disabled
for the current V1 scope. A configured key does not change that; nothing is
currently transmitted to Google through these routes. Dispatch planning uses a
local zone approximation instead. Before any later activation, these routes would
require renewed review:
Address completion in the job form. Input and the device IP address
could reach Google.
Dispatch map ("Live-Crew"). To display the map, the typed
job/customer address could be handed to a mapping library. Staff-location
coordinates remain disabled independently of this route (section 3).
Provider terms, account region and the data actually required must be evidenced
again before either route is activated.
Expo Push is technically disabled for the current V1 scope. The app does not
register for push, requests no permission for it, registers no new Expo token, and
the platform sends no message to Expo, Apple or Google. Historical tokens can still
be deleted.
Local reminders (optional). For a job with advance notice, the signed-in
person can explicitly choose "Reminder on this device". Only then does the app ask
the operating system for permission to show notifications. The reminder is
scheduled and shown on the device only. No push token is created and no data is
transmitted to Expo, Apple, Google or any other provider. The reminder text
contains neither names nor phone numbers. Scheduled reminders are removed when
travel starts, on sign-out and when local data is erased. The permission can be
withdrawn at any time in the device settings.
EAS/OTA runtime updating is also technically disabled. The app does not
request a runtime update from Expo; updates to this V1 are distributed only as
newly reviewed store builds. Other platform functions remain usable without
these two provider routes.
8. Disclosure abroad
The platform — application, database and file storage — has been operated
since 16 September 2026 at Exoscale (Akenes SA, Lausanne) in zone
CH-DK-2 (Zurich, Switzerland); the nightly backups are stored
encrypted in the same zone. In the current scope, disclosure abroad takes place
only through the remaining routes named in section 5: Resend and Stripe, as
well as — where enabled — sign-in with Google or Apple, may process data wholly
or partly outside Switzerland; Aiven Oy (Finland), as a sub-processor of
Exoscale, orchestrates the managed database whose data is stored in
Switzerland. On 28 September 2026 the three former Railway production
services were removed and each of the three original production volumes
received one supported, one-time wipe; no PITR card remains afterward, no
proven rollback exists. Protected Railway staging resources and three
new, service-less volume instances remain preserved unchanged pending a
further owner decision, and the current Exoscale production path
transmits no new data to these former Railway production services. The
Railway API still returns metadata for 18 historical backups;
whether their content remains recoverable or was purged by the provider is
unproven. The B2 remediation completed on 28 August 2026
removed the verified legacy health data from active primary storage; backups
at the infrastructure operator may retain remnants until their
scheduled replacement or deletion. New absence requests accept no medical
attachment or free-text reason. Routes expressly described in section 5 as
technically disabled receive nothing at present.
Art. 16 FADP applies to any disclosure abroad:
Data may be disclosed without additional safeguards to a state that the
Federal Council has listed in Annex 1 DPO as providing adequate
protection.
The United States has been on that list since 15 September 2024,
but only for companies certified under the Swiss-U.S. Data Privacy
Framework. Adequacy therefore depends on the individual recipient, not on the
country.
Absent adequacy, a safeguard under Art. 16 para. 2 FADP is required (in
particular standard data protection clauses approved by the FDPIC, or binding
corporate rules), or an exception under Art. 17 FADP must apply.
Where officially established, we already name the contracting party and country
in the table in section 5. Established to date:
Akenes SA (Lausanne, Switzerland) operates the platform as Exoscale
in zone CH-DK-2 (Zurich); its sub-processor Aiven Oy
(Finland, an EU member state and therefore listed in Annex 1 DPO)
orchestrates the managed database.
Railway operated the platform in the United States (US West,
sfo) until 16 September 2026; on 28 September 2026 the three
production services were removed and the three original volumes each
received one wipe. No final statement is made about remaining content,
recoverability or provider-side deletion; the executed Railway DPA
remains relevant for the earlier processing, not as the contract for
the current Exoscale operation.
Anthropic Ireland, Limited (Ireland) is the contracting party for the
Claude API for customers in Switzerland.
Stripe Payments Europe, Limited (Ireland) is the contracting party
outside North and South America; payment data is transferred to Stripe, LLC
in the United States.
Functional Software, Inc. (United States) operates Sentry and, per its
own contractual documents, bases transfers from Europe on the Data Privacy
Framework and, additionally, on standard contractual clauses.
As at 23.08.2026 the public Data Privacy Framework register lists
Railway (former), Sentry, Expo, Microsoft and Google
with an active Swiss certification; for Railway with the note that
re-certification is under review.
Resend is not certified for Switzerland. Its data processing
agreement provides for standard contractual clauses with Swiss adaptation for this
purpose. On 30 August 2026, the authenticated account document page and the
hash-bound provider-signed download were verified; the account documentation
states that the DPA becomes fully executed upon customer signup. This is contract
evidence, not legal certification.
The register distinguishes human-resources data from other data. Railway
(former) and Sentry are listed there for other data only. Whether the
historical backup metadata retained at Railway and the employee information
formerly processed there fall
within that is a legal question; we do not answer it
here and therefore do not claim that every disclosure is covered by adequacy.
Before any future activation of Sign-in with Apple, the following would
require renewed review: Apple Distribution International Limited
(Ireland) controls the personal data of individuals in Switzerland; it is generally
stored by Apple Inc. in the United States. Apple states that international transfers of Swiss data are governed by standard contractual clauses; whether and how that applies to this service and account must be evidenced before activation. The route is technically disabled at present.
9. Location access (technician app)
Capturing the device location of individual staff members is
disabled. No action in the technician app — a status update, photo
upload, warehouse scan, customer link, native status update, or a GPS form
field — produces a new coordinate today, regardless of whether a location
permission was granted. There is no continuous or background tracking.
Coordinates from before this was disabled may still be stored in job,
status, photo, scan or form records. These are no longer shown in any
output of the platform — including to the person's own company or
authorised roles — until a cleanup of this legacy data has been decided
(section 12). The only exception is the statutory access or data
portability response to the person concerned (section 15): for a registered
request with verified identity, it contains the coordinates attributed to
that person. The company's data export does not contain them.
The typed job/customer address is unaffected: in the current V1 it
is used only for the local zone approximation. The Google Maps routes are
disabled (section 6); the address concerns the job location, not a person's
location.
Any operating-system permission prompt can be revoked at any time in the
device settings; status reporting works in either case — with or without
location permission — without a new coordinate being produced.
The "Arriving in about" indication when setting off is not location data. It is chosen
(or left out) by the person themselves, and neither the device location nor a travel time
derived from location tracking is used.
10. Camera and photo access (technician app)
The technician app uses the camera to take photos evidencing work — for example
the work carried out, a delivery or a defect. The device's photo library is accessed
only when the user attaches an existing image to a job. Absence requests accept no images or files.
The technician app records neither video nor audio, and there is no continuous
visual monitoring. Capture takes place only upon an explicit action by the user.
Hidden details in photos. Photos often contain hidden extra details, such as where the picture was taken (GPS coordinates), the device used or editing details. iUseFlow removes these details from uploaded photos (JPEG, PNG, WebP) before they are stored; only the cleaned image is stored. This happens on the server, whether a photo is uploaded via the technician app or the web application. Images in other formats, such as HEIC, cannot currently be cleaned by iUseFlow; they are stored and output unchanged. The same applies to attachments of received e-mails. Photos stored before this cleaning was introduced remain stored unchanged, but are also output without these details — in the app, in the customer portal, in exports and in documents that are newly generated. Exceptions are sealed job reports and documents generated and filed earlier: they are always delivered exactly as they were created and may contain such an older photo together with its hidden details.
Browser speech recognition for service reports is disabled.
Scanning codes. In addition, the technician app uses the camera to read QR codes and barcodes. No photo is taken or stored; only the code read is used. A torch can be switched on, and without a camera the code can be entered by hand.
11. AI-assisted functions and automatic assignment
The external AI-provider route is technically closed. E-mail text, PDFs,
photos, supporting documents, health information and speech transcripts are not
transmitted to Anthropic. Any later activation requires a new documented provider
and data-flow assessment.
AI drafts (optional, switched off by default). iUseFlow is prepared
for AI drafts: a job draft from an e-mail or PDF, a report draft from spoken text,
a time entry from a short sentence, a structured damage report and an explanation
of the area suggestion. These functions are optional and switched off by default;
none of them is active today. Only once the platform releases them and your company
explicitly switches them on after the AI notice has been shown do they run on
Anthropic models via AWS Bedrock (EU) or Google Vertex AI (EU) or on
OpenAI models via Microsoft Azure (Switzerland), depending on
configuration; only with AI switched on; no use for training. Before sending,
e-mail addresses, phone numbers, IBANs, AHV numbers and known names are replaced
by placeholders; health information is never sent. Every result is a draft next
to the original that a person checks and confirms; the AI does not rate people
and does not decide any assignment. Only the function, model, token count, cost
and duration are logged, never the content.
Automatic assignment is disabled. Whether a job arrives through an
automatic interface — a connected mailbox, an interface or a webhook — or is
entered through the web interface, the platform does not assign it
automatically to a member of staff. It can at most show a
recommendation (the best-matching candidates, read-only); the actual
assignment is in every case an explicit, reviewed individual action
by dispatch. The assigned person sees the assignment in their job list in the app or the
web application; no push notification is currently sent for it (section 7).
Voice input. Browser speech recognition is disabled. The platform sends
neither microphone audio nor raw transcripts to a browser provider or Anthropic.
Your rights in this respect. If such an assignment leads in an individual
case to a decision with legal consequences for you or that significantly affects
you, you may under Art. 21 FADP state your point of view and request that the
decision be reviewed by a natural person. Please contact your company as controller
for this. Without a configured AI interface the platform's enabled core
functions remain usable; it then operates without this extraction.
12. Health data and high risk
New absence requests accept no health type, medical attachment, reason or
comment. On 28 August 2026 the verified legacy health data was deleted from
active primary storage. The atomic remediation deleted the sole target row and
generically redacted the related audit and notification rows; it left no active
primary row and no active blob reference.
The legacy data arose from earlier use of absence management. We expressly
do not base the processing on consent. In an employment relationship, consent is in the
FDPIC's view only rarely freely given, because the person is in a subordinate
position.
What governs instead is Art. 328b CO: the employer may process only
data concerning the employee's suitability for the job or necessary for performing
the employment contract. It must be able to evidence necessity and
proportionality; under Art. 362 CO this may not be departed from to the employee's
detriment, even with their consent.
Reading the legacy health-related information is disabled — for every
role, including owner, HR and the affected person themself. The category and
details are not output; list, calendar and planning views show only
"unavailable". The current state is primary_deleted_with_residuals,
not “fully deleted”: backups may temporarily retain the former row. The exact
target-bound remediation is reapplied before any restored data is used.
Processing such data may constitute a high risk within the meaning of Art. 22
FADP. If the statutory conditions are met, the company as controller carries out
a data protection impact assessment. This statement does not replace one: an impact
assessment requires a description of the processing, an examination of necessity
and proportionality, an evaluation of the risks and the measures envisaged.
13. Storage on your device
Public website: only if you consent to analytics under “Cookie
settings” do we count anonymously which of our pages are viewed (page, type of
source such as search or direct, device class, new or returning visit). Only daily
totals are stored, on our own server in Switzerland – no cookies, no IP address,
no device or personal identifier and no third party. Your browser keeps your
choice and a “visited before” marker. You can withdraw consent at any time under
“Cookie settings”.
Web application: browser local storage may contain session data,
cached job and inventory data, permissions, field configuration, language
and interface state. When the mobile app runs on the web, its session tokens
and device identifier are also stored there. Sign-out, the explicit local
erasure action or browser settings can remove these data.
Technician app: access and session tokens are held in the operating
system's secure storage. In addition, local work states and entries not yet
transmitted are stored so that the app can keep working without a connection. On sign-out, the session token and cached company information are removed.
Not removed are local work states and entries still queued in the outbox:
they are deliberately retained so that no recorded work is lost, and are
transmitted as soon as a connection is available again. What actually disappears when the app is
removed depends on the operating system: securely stored credentials can
survive a reinstallation. We therefore do not promise that deleting the app
removes all local data. You can revoke an existing device session from the app's
profile screen.
14. Retention
Job and assignment data is retained for the duration of the contractual
relationship between the company and iUseFlow. Within that frame the retention
period is determined by the company as controller.
Payroll-relevant details — working time, sickness absences, holidays —
are per the FDPIC generally to be retained for five years. Depending on
the category it is five to ten years.
Business and accounting records are subject to the ten-year obligation
under Art. 958f CO. That period concerns bookkeeping — not every personnel or
health record.
After the employment relationship ends, only details that are essential,
legally required or needed for a dispute may still be kept; everything else is to
be destroyed once it is no longer required.
Error logs and technical data are retained only for as long as
necessary for operation, security and error correction.
Personal customer links ("Your appointment") are valid at most until the day after the appointment, for another 24 hours after the job is completed, no longer after a cancellation and in no case for more than 30 days after the last extension. If a sealed job report exists, the link is valid for 30 days from sealing; the company can revoke it at any time. Links for appointment proposals are valid for 7 days. Requests counted to protect against abuse are no longer taken into account after 10 minutes. Appointment proposals, customer links and the points in time relating to the customer copy are deleted together with the job.
Defects and damage reports are kept as long as their job exists – even when they are fixed, discarded or closed – and are deleted together with the job, including their history. Their photos are not deleted with them: like the other photos of a job, they remain stored in the file storage; the following paragraph applies to them. No separate retention period has yet been set for defects and damage reports.
The profile photo stays stored until the person or the office removes or replaces it, or until the person is archived. iUseFlow then removes the reference immediately and deletes the image file from the file storage as soon as nothing else uses it; the following paragraph applies to backup copies.
Fleet data stays stored while the vehicle is active; a retired vehicle stays archived with the company’s other data and is no longer assigned. Daily assignments stay stored like job data; when a person is archived, iUseFlow removes their future daily assignments. The vehicle given on a job is deleted together with the job. Equipment carried by an archived person stays linked to them until the office hands it over to a vehicle or another person.
Job duration, crew confirmation and delay reports: duration corrections, crew entries and delay reports are kept like the job data and deleted with the job.
Short feedback and “Good to know”: the information is kept as long as the customer record exists and is deleted with it; without a customer link it is deleted with the job. The office can delete individual entries at any time.
“Who is away” and tapped clock times: the team view stores no data of its own; it shows the existing absences. Tapped clock times are part of the working-time records and are kept like them; the log entry about the server receipt is kept like the other log entries.
Shift schedule and confirmed planned times: published and cancelled shifts are kept like the working-time records; a draft that was never published can be deleted. Times confirmed from the plan are part of the working-time records and are kept like them. A message about the shift schedule is replaced as soon as a new one is created.
Time inbox and timesheets: office entries and the noting of a notice are part of the working-time records and are kept like them. Timesheets are not stored; the log entry for the request is kept like the other log entries.
Team chat: the thread of a job is deleted with the job, including photos. Messages in team channels and «Whole company» are deleted, including photos, after the period set by the company (12 months by default, adjustable from 1 to 36 months); a deleted channel is deleted with all its messages. Your own read marker is deleted with the channel or with your membership.
What we must say honestly here: there is currently no automatic
deletion at the end of the contract. Deletion happens on express request. New
medical absence information is not accepted; the verified legacy health data was
deleted from active primary storage on 28 August 2026. Backup copies remain
at the infrastructure operator, as do retention periods
at the recipients named in section 5; deletion at our end does not take immediate
effect there. Binding periods per data category are currently being established.
15. Your rights
Under the FADP you have in particular:
the right of access to the data processed about you (Art. 25 FADP);
the right to rectification of inaccurate data (Art. 32 FADP);
the right to erasure or destruction, unless a retention obligation
prevents this;
the right to object to processing;
the right to release or transfer of data in a common electronic format
(Art. 28 FADP).
Address your request first to your company as controller. For matters concerning
account, contract or billing data, contact
info@iuseflow.ch. We must verify your identity
in order to act on the request; for that we ask only for the information necessary.
You also have the right to contact the Federal Data Protection and Information
Commissioner (FDPIC), Feldeggweg 1, 3003 Bern.
16. Account deletion
The technician app does not create accounts. Access is set up and administered
exclusively by the company (your employer) as controller; for that reason the app
deliberately has no button with which an employee could delete their own company
account. Working times, signatures and completion records are attached to an
account, for which the company bears statutory retention obligations.
You can request deletion of an account and the associated data as follows:
Contact your company (your employer) as controller first. It can deactivate
access at any time and request deletion from the platform operator.
You may also contact the platform operator directly at
info@iuseflow.ch. We forward the request to
the responsible company and carry out the deletion once it has approved.
The user account and the personal information tied to it are deleted. Data
subject to statutory retention obligations (e.g. working-time and billing data) is
retained until the relevant period expires. The deletion that follows does not
happen by itself: section 14 applies — we delete on express request, binding
periods per data category are currently being established, and backup copies as
well as retention periods at the recipients persist independently.
17. Data security
Access runs exclusively over HTTPS/TLS. Each company is a separate tenant;
accesses are confined to the company's own data. Access is role-based, sessions are
time-limited, and two-factor authentication is available. Further information is
available under Security.
18. Contact
For questions about data protection, contact the responsible company (your
employer) or the platform operator:
iUseFlow, Abdi-Aziz Ibrahim, Hofwiesenstrasse 158, 8057 Zurich, Switzerland
E-mail: info@iuseflow.ch
Further details in the legal notice.
19. Changes
The version published here governs. The current version bears the date given
above. We notify the company of material changes.