End-user terms
Last updated 12 October 2026
Sientus Solutions' cloud apps on the Atlassian Marketplace are provided under the Bonterms Standard End User Agreement (Version 1.0) (the "Standard Agreement") together with these Provider-Specific Terms, ranked as Section 1.4 (Order of Precedence) of the Standard Agreement provides. Atlassian runs the Marketplace but is not a party to either. Capitalised terms have the meanings the Standard Agreement gives them.
1. Provider and notices
Provider is Sientus Solutions, a sole proprietorship (enkeltmandsvirksomhed) registered in Denmark under CVR number 39012308, at Nørre Alle 22, 2600 Glostrup, Denmark.
For Section 19.3 (Notices), Provider's address is contact@sientus.com for email and the address above for post. Customer's notice address is the billing and technical contacts that the Atlassian Marketplace shares with Provider for Customer's licence, or another address Customer gives by notice. Where no usable contact exists, Provider may give notice through the Product.
2. Products covered
These terms cover every cloud app that Sientus Solutions builds on Atlassian's Forge platform and lists on the Atlassian Marketplace with a Listing that names these terms. Each is a Product. Today there is one:
| Product | Documentation | Support Policy | DPA schedule |
|---|---|---|---|
| Intake Standards for Jira Service Management | docs.sientus.com/intake-standards | Support | Schedule A |
3. Attachments
These Attachments are identified for the Standard Agreement:
- DPA, for Section 3.3 (DPA): the Bonterms Data Protection Addendum (Version 2.0, Attachment Version) as completed by Provider's DPA Details at docs.sientus.com/legal/dpa.
- Support Policy, for Section 5.1 (Support): the support page of each Product, listed in clause 2. Customer can always reach Support at contact@sientus.com, whether or not a Product's support portal is open. For the Support Policy, a business day is Monday to Friday, except Danish public holidays and 24 December to 1 January, and support hours are those the support page states.
- Security Measures, for Section 3.2 (Security): the technical and organisational measures in the Security Measures part of the DPA Details.
No SLA is identified for Section 5.2 (SLA).
4. Governing law and courts
For Section 19.2 (Governing Law and Courts), the Governing Law is the laws of Denmark, excluding its conflict-of-laws rules and the United Nations Convention on Contracts for the International Sale of Goods. The Courts are the courts of Denmark.
5. Additional Terms
5.1 Atlassian platform. Each Product is a Forge app. Its code runs and its data is kept on Atlassian's Forge platform, and it works inside Customer's Atlassian products, such as Jira Service Management. Customer's Atlassian products are Third-Party Platforms under the Standard Agreement, and each Product depends on them. Atlassian runs Forge for Provider as a subcontractor under Section 19.9 (Subcontractors), and processes personal data for the Products as Provider's Subprocessor under the DPA.
5.2 AI check. Where a Product uses Atlassian-hosted AI (Forge LLMs), as the check in Intake Standards for Jira Service Management ("Intake Standards") does, the AI judges text against the checks that Customer configures. Its results are automated judgements and can be wrong. Customer decides how to use them, and remains responsible for its intake standards and for its decisions about requests. Provider does not use Customer Data to train or fine-tune any AI model. In Intake Standards, the field tells requesters above the box that AI checks their text.
5.3 Users, Customer Data, export and deletion. Customer's portal customers and other people who use a Product only through a request form on Customer's site are permitted as Users under part (b) of the definition of "User" in Section 20 (Definitions). Customer Data includes what they enter in a Product. For a Forge app, Section 12.4 (Data Export and Deletion) works as follows.
(a) Export. A Product has no bulk export. During a Subscription Term, Customer can read its data in the Product as the Documentation describes. In Intake Standards, project admins read every version of every intake standard on the Intake standards page under Project settings, and the checks of the last 30 days on the Run log tab.
(b) Deletion. In Intake Standards, each run log row expires 30 days after it is written, and Forge deletes it within about 48 hours; intake standards stay while the Product is installed. When Customer uninstalls a Product, Atlassian keeps the Product's hosted storage for 28 days and then deletes it. After this Agreement ends, Customer requests deletion under Section 12.4(b) by uninstalling the Product, and Atlassian deletes its hosted storage within the 60 days that section allows. If Customer asks Provider in writing instead, Provider tells Customer how to uninstall.
(c) Data in Customer's Atlassian products. Data a Product writes into Customer's Jira, such as a copy of the requester's text in Description, labels, internal notes and issue properties, is held in Customer's Atlassian products under Customer's control and its agreement with Atlassian, and stays there when the Product is uninstalled. Uninstalling removes a Product's custom fields and their values; they return if the Product is reinstalled within 30 days.
5.4 Advisory mode. Intake Standards has an advisory mode, in which the checks still run and their results are recorded, but nothing stops a requester from sending a request. Provider may switch the Product to advisory mode for all installations while an incident affects the check, and switches it off once the incident ends. Provider tells Customer's technical contact by email, and on the Product's support page, when it switches advisory mode on and when it switches it off. A project admin can still disable any standard at any time. An installation without an active licence shows the plain required box: no checks run and nothing is sent to the model, and its standards and run log are kept. Each installation has the monthly run budget the Documentation states; once it is used up, checks are refused until the next month and requests are sent labelled for review.
5.5 Fees and refunds. Customer orders and pays through the Atlassian Marketplace, on its terms; Atlassian collects the fees as Provider's commercial agent. Atlassian makes the refunds that the Atlassian Marketplace Terms of Use provide, including the return of an initial Order within 30 days. Where the Agreement requires Provider to refund fees (Sections 6.2, 15.5 and 19.8 of the Standard Agreement, and Section 4.4 (Objection to New Subprocessors) of the DPA), the refund is made through the Atlassian Marketplace where Atlassian can process it; otherwise Provider pays it to Customer directly.
5.6 Usage Data. For a Product, Usage Data under Section 3.4 (Usage Data) is what the Forge developer console shows Provider about the Product: its log lines, while Customer's site admin leaves app-log access enabled, and the usage metrics Atlassian provides for it. In Intake Standards, log lines carry ids, versions, outcomes, error codes, timings and token counts, never requester text or account ids.
5.7 Sensitive Data in free text. For Section 7.2 (High-Risk Activities and Sensitive Data), Customer does not submit Sensitive Data only because a requester or other person types it into a Product's text field without Customer asking for it, provided Customer does not design its request forms or intake standards to collect it and tells requesters not to include it.
5.8 Continuity. Each Product runs on Forge with no server of Provider's. If Provider stops supporting a Product, it tells Customer's billing and technical contacts at least 30 days before, and refunds prepaid fees for the time after support ends, as clause 5.5 provides. Project admins can stop a Product's checks without Provider, and the data the Product wrote to work items stays in Customer's Jira.
5.9 Language. The Agreement is made in English. The English text prevails over any translation, including any translation of the Standard Agreement. Provider gives Support and notices in English.
6. Changes to these terms
Provider publishes each version of these Provider-Specific Terms and of the DPA Details at its own permanent address, with its effective date. Provider tells Customer of a new version by email to Customer's billing and technical contacts at least 30 days before it takes effect. A new version applies to Orders placed on or after its effective date. For a renewal of an existing Subscription, it applies from the first renewal at least 30 days after Provider has emailed it; until then, the version in force when the Order was placed continues. Changes to the Support Policy and the Security Measures follow Section 19.6 (Operational Changes). Atlassian does not move an app to a new version of the Standard Agreement automatically, so a new version applies only if Provider adopts it through a new version of these terms.