Support

Support

For: Approval Flow for Jira and Attestation Flow for Confluence, the Atlassian Forge apps published by Stanki Guild sp. z o.o.

Last updated: 12 October 2026

09:00-17:00, Monday to Friday, Europe/Warsaw (CET/CEST), excluding public holidays in Poland.

Requests raised outside these hours are queued and the response clock starts at the beginning of the next business day. Severity 1 is the exception (see §3).

These are response targets: the time within which a human replies with an assessment and a plan. They are not resolution times, because a resolution time that depends on the nature of an unknown fault would be a number we could not honour.

Target fix times follow the same ordering, but we commit to a plan, not a date, at first response: S1 is worked continuously until resolved or downgraded; S2 is targeted at the next release; S3 and S4 are scheduled and you are told which release to expect.

Security vulnerabilities run on a separate, faster track with their own targets (see §6 and the Security Policy).

We set the severity, from what you tell us. If you disagree with an assignment, say so in the ticket and we will re-assess. Marking everything S1 does not make anything faster; it makes the real S1s harder to find.

When we cannot fix it. Some faults are in the Atlassian platform, not in our app. When that is the case we will say so explicitly, tell you what we have observed, raise it with Atlassian, and give you the ticket reference, rather than leaving you waiting on us for something we do not control.

The single biggest cause of a slow answer is a report we cannot reproduce. Please include:

1. Which app and which product: Approval Flow (Jira) or Attestation Flow (Confluence).
2. Your Atlassian site URL (https://yourcompany.atlassian.net).
3. What you expected to happen, and what happened instead. In that order, in one sentence each.
4. Exact steps to reproduce, starting from a screen you can name.
5. Where you were: the issue panel, the glance, the project page, the admin page, the macro, the byline, the dashboard, the space report.
6. When it happened, with a timezone. A timestamp lets us line your report up against platform events.
7. How many people are affected, and whether it is blocking work.
8. Your role: site admin, project admin, or standard user. Several behaviours differ by permission.
9. Screenshots of the failing screen, including any error message in full.
10. Browser and version, if the problem is visual or a click does nothing.

Please do not send us production data. We have no access to your site, and we do not want a copy of your records. Redact issue and page content, personal data, and anything confidential before you attach a screenshot. Never send credentials, API tokens or session cookies: we will never ask for them, and any that arrive will be deleted and you will be told to rotate them.

If we need more than a screenshot, we will ask for a specific, minimal thing (for example, a record ID, or a screen recording of a reproduction on test data) and explain why.

Some worked examples, so the table in §3 has edges:

• S1: a workflow validator blocks every transition for every user in a project; acknowledgement receipts are recorded against the wrong person; the panel fails to load for everyone after an upgrade.
• S2: group-based approvers are not resolved for one group, so a quorum can never be met; the compliance dashboard shows stale figures for a whole space.
• S3: a due date renders in the wrong format; the report is correct but confusing; "how do I configure X?".
• S4: a label is misspelt; a column would be better sorted differently; a request for a new capability.

An issue that is genuinely urgent for you but does not match S1 will not be downgraded out of spite: tell us why it is urgent and it will be weighed.

Do not report a vulnerability to support@stankiguild.com or in a public forum. Email security@stankiguild.com.

Those fix targets are Atlassian's Marketplace Security Bug Fix Policy for cloud apps, which we are held to. Good-faith research has our safe-harbour commitment; we run no paid bug bounty. Full details, including what security assurances we do not have, are in the Security Policy.

Our apps are paid via Atlassian, which means Atlassian is the merchant of record. Atlassian handles purchase, renewal, invoicing, tax and refunds: we do not have access to your billing account and cannot issue an invoice or a refund.

• Licence, quantity, invoice, renewal or refund questions → Atlassian Support (https://support.atlassian.com) or your Atlassian account's billing screen.
• "My licence is valid but the app says it is not" → that is ours. Email it to support@stankiguild.com as S2, with your site URL and the screen you are seeing.

A 24×7 emergency contact for Stanki Guild sp. z o.o. is registered with Atlassian in our Marketplace Partner account, as Atlassian requires of every paid-via-Atlassian partner. It exists so that Atlassian can reach a responsible human out of hours about a platform-level or security incident affecting our apps.

It is not a customer hotline and is not published here. Customers reach us through support@stankiguild.com, at the severities and response times in §3, where S1 is answered within 24 hours including outside business hours. Vulnerability reports to security@stankiguild.com are acknowledged within 2 business days, during business hours; a suspected active security incident reported there is answered within 24 hours, including outside business hours.

If Atlassian Cloud itself is degraded, check https://status.atlassian.com first; when the platform is down, our apps are down with it and there is nothing we can deploy that changes that.

Covered: installation and configuration questions; defects in the apps; questions about behaviour, permissions and licensing state; guidance on data handling, retention and uninstall; documentation gaps; feature requests (logged, prioritised, no promise of delivery).

Not covered: customisation of your Jira or Confluence instance; writing your JQL, automation rules or workflows for you; third-party apps; training; and anything requiring access to your site: we have none, by design, and will not ask for admin credentials or a screen-share of production data.

Stanki Guild sp. z o.o. · ul. Adama Mickiewicza 13/4, 82-300 Elbląg, Poland