Service Level Agreement (EU)

1. Subject matter

1.1 The following provisions of this Service Level Agreement (SLA) specify the services owed by the Provider under the contract agreed with the Customer (the “Main Agreement”) and the agreed service quality and availability of those services. This SLA forms part of the Main Agreement. In the event of conflicts between the constituent parts of the contract, the order of precedence agreed in the Main Agreement applies (clause 18.1 of the Terms).

1.2 Scope. This SLA applies to the Flip platform and to the modules and additional services ordered by the Customer, in particular Flip Fusion, Flip Flows and gyde (Flip Learning), provided that the relevant feature is generally available and that no separate SLA has expressly been agreed for the service concerned. Frontline Identity by Flip is governed exclusively by the SLA Frontline Identity; this SLA does not apply to Frontline Identity. Clause 1.8 remains unaffected.

1.3 Applications created by the Customer (Flip Fusion). For Flip Fusion, this SLA applies to the availability and operation of the Fusion environment (builder, runtime environment and storage) at the handover point. It does not apply to the applications created by the Customer using Flip Fusion (the “generated apps”) themselves, in particular not to their functionality, fitness for the purpose pursued by the Customer, freedom from errors, performance or output quality. These depend substantially on the Customer’s inputs, configuration and integrated interfaces and are outside the Provider’s sphere of influence (clause 2). Incidents affecting only individual generated apps are not incidents within the meaning of clause 5.6 and trigger neither response times nor service credits.

Where generated apps are connected to systems of the Customer or of third parties, this SLA applies only to the connector component provided by the Provider up to the handover point. If the parties disagree as to whether the cause of an incident lies in that component or in the Customer’s inputs, configuration or connected systems, the parties shall cooperate in narrowing down the cause; the Provider owes services under this SLA only once it is established that the cause lies within its sphere of responsibility.

1.4 Automations configured by the Customer (Flip Flows). For Flip Flows, this SLA applies to the availability of the Flows execution environment at the handover point. It does not apply to the flows created or configured by the Customer themselves, in particular not to their substantive correctness, fitness for the purpose pursued by the Customer, execution result or execution time, to the extent these result from the design of the flow, from the triggers, conditions and data mappings set by the Customer, or from connected systems of the Customer or of third parties. If execution does not take place because a triggering event in the Customer’s system was not transmitted or was transmitted incorrectly, there is no incident within the meaning of this SLA. Clause 1.3, fifth sentence (narrowing down the cause), applies accordingly.

1.5 AI-assisted features. AI-assisted features do not produce results deterministically. Divergent, incomplete or substantively incorrect results are not an incident within the meaning of this SLA, provided that the feature is technically available and the results fall within the mode of operation described in the service description. Clause 3.4 applies to outages of the model and inference services used by the Provider.

1.6 Quotas. The unavailability of a feature because contractually agreed quotas have been reached (for example the number of generated apps that can be published, or execution or processing quotas) is not an incident within the meaning of this SLA.

1.7 Amendments to this SLA. The current version of this SLA is available at https://www.getflip.com/legal/sla-uk/ (United Kingdom and other countries) and at https://www.getflip.com/legal/sla-usa/ (United States). For the term of the Main Agreement, the version that became part of the contract at the time the contract was concluded applies. The Provider is entitled to develop and adapt this SLA. Amendments affecting the agreed service levels, the scope of services or the Customer’s obligations are not made unilaterally during the current contract period; they are announced to the Customer in accordance with clause 17 of the Terms and take effect for the existing contract at the earliest from the next renewal date. Purely editorial amendments and amendments that do not disadvantage the Customer (in particular extensions of the scope of services or improvements to the service levels) may be made by the Provider, following prior announcement, with effect for the current contract period as well.

1.8 This SLA does not apply to services provided free of charge, to free trial versions, or to test systems and features made available as beta, pilot, preview, early access or under a comparable designation (clause 2.11 of the Terms), including pilot projects or test installations.

1.9 Transition from a test version to the full version. Where a feature was initially made available to the Customer under clause 1.8 (in particular as a free trial, pilot, preview, early access or test installation) and is subsequently made available as a generally available full version owed against payment, this SLA applies to that feature from the beginning of the first full calendar month following its activation for the Customer. The Provider notifies the Customer of the activation and of the relevant effective date in text form. Periods prior to that date are disregarded when determining system availability (clause 3), when calculating service credits (clause 7) and when counting consecutive months under clause 8. The basis for calculating service credits is the monthly fee separately shown for that feature in the order form from the effective date; where no separate fee is shown for the feature, outages affecting only that feature do not trigger service credits.

2. Reference system

2.1 All performance figures in this SLA relate to the quality owed by the Provider of the software service offered to the Customer for use, measured at the handover point of the data network or service operated by the Provider. Impairments outside the Provider’s sphere of influence are disregarded. This is the case, for example, with the Customer’s IT systems, the general internet infrastructure, global cloud outages, internet domains administered by the Customer, generated apps created by the Customer, and interfaces and third-party applications integrated by the Customer.

2.2 Relationship to Frontline Identity. If Frontline Identity fails, the Customer’s claims are governed exclusively by the SLA Frontline Identity. Periods during which access to the software service is impossible solely because of an incident affecting Frontline Identity count as excluded downtime within the meaning of clause 3.4 of this SLA. Service credits are not granted twice under both SLAs.

3. System availability

3.1 The Provider offers use of the software service at the handover point with a system availability of 99.5% per calendar month. The handover point is defined as the reachability of the address https://<organization domain>/status. The system is available where the following conditions are met at the same time:

• a) the HTTP request is answered with HTTP status code 200;

• b) the content of the JSON response contains the key “status” with the value “ok”;

• c) the response is delivered in less than 3 seconds.

3.2 The percentage for system availability is calculated as follows:

3.3 “Downtime” means the total number of minutes in the month during which the software service is unavailable at the defined handover point. Excluded downtime is not counted.

3.4 “Excluded downtime” means the total number of minutes in the month attributable to the following:

• maintenance or other services agreed with the Customer which prevent access to the software service. The Provider will make commercially reasonable efforts to carry out regular planned maintenance outside normal operating hours in the Customer’s respective hosting region. These are specified in the table “Maintenance windows by region” below. The maximum permitted interruption of the service is 6 hours per maintenance window, and the total duration of planned maintenance may not exceed 16 hours per calendar month. Maintenance is generally announced at least one working day in advance; as a rule, however, this is done 7 calendar days before the planned maintenance date.

Maintenance windows by region

The following maintenance windows apply to customers hosted in the respective regions. All times refer to the applicable local summer or winter time.

• unforeseen and urgently required unplanned maintenance, where such work could not have been avoided even with reasonable care and planning;

• periods of unavailability due to factors outside the Provider’s control (for example unforeseeable events which could not have been avoided even with the Provider’s reasonable care, or downtime for which third parties are responsible); downtime caused by third parties;

• downtime due to denial-of-service, malware or hacker attacks, provided that the Provider has taken reasonable protective measures and the attacks could not have been avoided even with the Provider’s reasonable care;

• downtime due to the Customer’s specifications or instructions, due to unavailability of the Customer’s equipment or due to other interruptions caused by the Customer (for example failure to provide required cooperation);

• downtime for the installation of urgently required security patches;

• downtime due to software errors in customer or integration applications, or due to errors in the system software and system-related software triggered by customer applications or data;

• downtime attributable solely to generated apps created by the Customer using Flip Fusion, to their configuration, or to interfaces integrated by the Customer (clause 1.3);

• downtime attributable solely to flows created or configured by the Customer, to their triggers, conditions and data mappings, or to connected systems of the Customer or of third parties (clause 1.4);

• periods during which an AI-assisted feature (in particular Flip Fusion and AI steps in Flip Flows) is unavailable or only partly available solely because a model or inference service used by the Provider fails, rejects requests, applies rate limiting, or because a model is changed or discontinued by the model provider, provided that the Provider makes reasonable efforts to restore the feature via an alternative deployment or an alternative model;

• downtime due to an incident affecting Frontline Identity (clause 2.2);

• downtime attributable to features excluded from the scope of this SLA under clause 1.8; or

• downtime caused by outages of the general internet infrastructure (for example DNS problems or internet BGP routing) or by global cloud outages.

3.5 It is incumbent on the Customer to report impairments of the use of the software to the Provider. The Provider will endeavour to remedy impairments without undue delay. There is no claim to restoration of the usability of the software service where the agreed system availability is met.

3.6 Where the Provider does not make the software service available in accordance with the contract within the agreed system availability, the Customer is entitled to restoration of availability in accordance with this SLA.

4. Priorities

Where the Provider’s services do not meet the values set out in this Service Level Agreement, the Provider shall, in the event of impairment of both system availability and service quality, first restore the data security of the services and the system availability of the services, then the owed data throughput and response times. The Provider may change the priorities where this is technically necessary or appropriate.

5. Incident reports, restoration of services

5.1 The Customer may report a failure to meet system availability as an incident.

5.2 The Customer shall report incidents to be handled under this SLA as follows:

Form: https://flipappsupport.zendesk.com/hc/en-gb/requests/new for contacts, stating the request priority and a detailed description of the incident.

Incident reports received are confirmed to the Customer in writing (by email or ticket). The persons authorised to report incidents and to take decisions regarding the Flip system are dealt with in detail in clause 6.2.

5.3 The Provider handles incidents and incident reports during the following service hours: 7 days a week, 24 hours a day.

For the features “File Storage” and “SharePoint Integration”, the Provider handles incidents and incident reports during the following service hours: Monday to Friday, 07:00 to 20:00 CET.

5.4 The Customer shall report incidents to be handled under this SLA only through employees trained and authorised for that purpose. Where the Customer reports an incident, it shall provide the Provider with the description of the incident in accordance with clause 5.6 as far as possible (for example in the case of problems with an identity provider for which the Provider is not responsible, such as Microsoft Entra ID). When reporting the incident, the Customer shall state which persons are available to the Provider as contacts at the Customer for that incident and how they can be reached by telephone. Contacts shall be named in such a way that the Provider can always contact one of the named contacts directly for the duration of the incident.

5.5 The Customer can view the current status of the incident and the incident report at https://www.getflip.com/status/.

5.6 Incidents subject to the provisions of this SLA are classified as follows:

Impairments which fall outside the scope of this SLA under clauses 1.2 to 1.6 or 1.8 are not classified in accordance with this table; their handling is governed by the Main Agreement.

5.7 Where an incident reaches a higher priority level, the Customer shall notify the Provider without undue delay. Measurement of the response time begins as soon as the Customer’s incident report (clause 5.4) is received by the Provider. The assignment of an incident to an incident class is determined by whether the characteristics stated in the incident description are present. The Provider may reassign the priority at its reasonable discretion on the basis of the criteria in clause 5.6.

5.8 Upon receipt of a proper incident report from the Customer, the Provider undertakes to begin the analysis and, where possible, the remedy of the incident within the response times specified at the latest. Work to remedy incidents is carried out within the Provider’s means and in compliance with its contractual obligations. The agreement of response times does not give rise to a claim to remedy the incident within a particular time.

5.9 There is no incident to be remedied by the Provider in the case of impairments of data transmission outside the data network operated by the Provider, for example due to line failure or line disruption at third parties, or in the case of use of the provided system capacities in breach of contract, for example through an excessive number of accesses by the Customer.

5.10 The handling of incidents not defined in clause 5.6 is governed by the Main Agreement.

6. Monitoring, contacts, assertion of claims

6.1 The Customer has access to, and is responsible for checking, the monthly system availability of the software service at the following page: https://www.getflip.com/status/.

6.2 The Customer shall provide the Provider with up-to-date contact details (name, email, telephone) of the responsible contacts, or of those authorised to report incidents, to whom all communication in connection with this SLA is to be addressed (for example announcements of maintenance, delivery of requested SLA reports and communication in emergency situations). The Customer shall ensure that these contacts can be reached reliably and that they are sufficiently enabled, informed and authorised in line with the requirements of the Flip system integration (for example the Customer’s internal and central IT standby team).

6.3 The Customer is entitled to the rights under clauses 7 and 8 only if it notifies the Provider of their assertion in writing without undue delay, and at the latest within two weeks of the occurrence of the incident giving rise to those rights.

7. Payment obligation in the event of an incident

7.1 The following provisions supplement the statutory warranty provisions without displacing them. The Customer is entitled at any time to assert the rights available to it on account of the unavailability of the systems, the failure to grant use of the software, and breaches of duty in performing the services under the Main Agreement. Where it asserts those rights, it may assert the following rights only to the extent that they go beyond them.

7.2 Where the software service does not achieve the contractually agreed system availability in a given calendar month and such a failure is reported by the Customer and verified by the Provider in accordance with this SLA, the following applies: the Customer is entitled to liquidated damages in the form of credited service credits in accordance with the table below. Service credits are calculated on the basis of the monthly fee for the affected software service; where the unavailability affects the Flip platform as a whole, the total monthly fee is decisive:

7.3 Service credits may be applied immediately, and at the latest within two months, to the invoice following the stated unavailability. Service credits may only be applied to invoices issued under the Main Agreement and cannot be paid out or redeemed against any other consideration. A reduction on account of unavailability is set off against service credits and vice versa (clause 13.2 of the Terms). The Customer’s rights under clause 7.1 and the termination rights under the Main Agreement remain unaffected.

8. Termination in the event of unavailability

Where the system availability referred to above is not achieved and the Customer is entitled to receive service credits in two consecutive months within a period of 12 months, the Customer may terminate the Main Agreement in writing with immediate effect. To do so, it must give written notice to the Provider within 8 weeks of the event giving rise to the termination. The termination rights under clause 16 of the Terms remain unaffected.