A field guide for Atlassian Solution Partners
Three apps for small gaps, and when to use something else.
For consultants who keep meeting the same kind of gap at customers in Jira, Jira Service Management or Confluence: real, too small to justify a project, and not quite closed by configuration or Automation. Each app below says what it replaces and where it stops, so you can tell a customer quickly whether it fits.
Eriksen Labs is one person in Norway. The person who answers your email wrote the apps.
- Hosting
- Atlassian Forge. Eriksen Labs runs no servers for the apps.
- Egress
- None declared, in any of the three.
- Data
- Held in the customer's Atlassian site. The apps send nothing outside Atlassian, and Eriksen Labs cannot read it.
- Runs on Atlassian
- Mermaid Diagrams & Gantt and Recurring Requests carry the badge.
- Resale
- Through the Atlassian Marketplace, for the two apps listed there.
- Evaluation
- Prices and a free trial on each Marketplace listing.
Which app fits?
Start from what the customer describes. Where native Jira, Automation or another kind of tool is the better answer, this guide says so.
- Engineers already write Mermaid, and the diagrams in Confluence are screenshots nobody can edit.
- Eriksen Labs app Mermaid Diagrams & Gantt
- PlantUML, OpenAPI or Swagger and other formats, across many teams, in one app.
- Another kind of tool A broad technical-content suite
- Portal customers want to set up, pause and cancel their own recurring requests.
- Eriksen Labs app Recurring Requests & Templates
- An admin wants the same ticket created on a schedule, for the same team with the same fields.
- Native Jira Automation's scheduled trigger
- Issues arrive without what the team needs, and each issue type should start from its own description, without another custom field.
- Eriksen Labs app, awaiting Marketplace approval Issue Templates & Create Defaults
- Filling a field after the issue has been created is good enough.
- Native An Automation rule on Issue created
- The gap needs a small extension of its own, or a private Connect app has to move to Forge.
- Fixed-scope build Forge Extension Sprint
Mermaid Diagrams & Gantt
On the Atlassian Marketplace · Confluence Cloud
Diagrams written as Mermaid text inside Confluence pages, with a live preview, syntax highlighting, eight starter examples, validation that blocks saving a diagram that will not render, and the last five saved versions of every diagram. Diagrams download as SVG or PNG and are included as pictures when a page is exported to PDF or Word. Diagrams saved before version 2.4 need one open and save to get their picture, and so do diagrams saved before 2.6 that set their own theme or colours. Until then, Word shows their text as code, and a PDF of a page with many of them can fail (known issue). The app requests no permission scopes and declares no egress: diagram text is stored in the page and rendered in the reader's browser. Page exports, page history and notification emails use the app's own function on Atlassian's platform, which keeps nothing.
When a customer says…
- “Our engineers write Mermaid in GitHub already. Confluence should render it too.”
- “The architecture diagrams in Confluence are screenshots nobody can edit any more.”
- “Security will not approve a diagram app that can read our pages.”
- “We want the project's Gantt chart on the project page, kept as text next to the plan.”
What it replaces
- Diagram screenshots pasted into pages and left to go stale
- Mermaid kept in code blocks that never render
- A general-purpose diagram app installed for a team that only ever writes Mermaid
Where it stops
- Mermaid and nothing else. It does not replace a broad technical-content suite: if the customer wants PlantUML, OpenAPI or Swagger rendering and other formats across many teams in one app, a suite that covers all of them is the better fit.
- Not a drag-and-drop whiteboard. Teams who would rather draw than write text are better served by a drawing tool.
Evaluation and resale
- Prices and a free trial on the Marketplace listing for Mermaid Diagrams & Gantt
- Partner resale through the Atlassian Marketplace
- Carries the Runs on Atlassian badge on the Marketplace
Recurring Requests & Templates
On the Atlassian Marketplace · Jira Service Management Cloud
Portal customers repeat a request they have already raised: once, on a schedule, or from a saved template. The customer owns the schedule and can pause, resume or cancel it from the portal without asking an agent. The admin sets the limits per project: which request types may repeat, the shortest gap between repeats, how far ahead a schedule may run, and how many schedules one customer may hold. Scheduling is off until an admin turns it on. Repeats are raised as the customer, so they follow the request type's workflow and count towards SLAs.
When a customer says…
- “Our customers email us every month asking us to raise the same request.”
- “Customers want to schedule their own quarterly access reviews, and stop them when they no longer need them.”
- “We keep one Automation rule per customer for their recurring requests, and nobody wants to own them.”
- “A customer should be able to pause it over the holidays without raising a ticket about it.”
What it replaces
- Customers emailing an agent to raise the same request again
- Reminders in the customer's own calendar
- Per-customer scheduled Automation rules that an admin has to create, change and retire on the customer's behalf
When Automation is the better answer
- An admin owns a simple recurring job, such as the same ticket created every Monday for the same team with the same fields. Jira Automation's scheduled trigger does that natively. Use Automation.
- This app earns its place only when the portal customer has to own the recurrence: set it up, pause it and cancel it themselves, within limits the admin sets.
- Limits to mention: attachments are not copied to a repeat. Fields that point at another record, such as Affected services, are left blank on the repeat and named so they can be chosen again.
Evaluation and resale
- Prices and a free trial on the Marketplace listing for Recurring Requests
- Partner resale through the Atlassian Marketplace
- Carries the Runs on Atlassian badge on the Marketplace
Issue Templates & Create Defaults
Submitted to the Atlassian Marketplace, awaiting approval · Jira Cloud
A default for each project and issue type, filled into Jira's own Create dialog: Summary, Description, a checklist, Labels and Priority. Once the person writes their own summary or description, the app backs off and writes nothing more to that form. It adds no custom fields. Project administrators manage their own project's templates without going through a Jira administrator. Every template keeps its last 50 versions, a deleted template can be restored for 30 days, and a daily check reports templates that have stopped working because the project's configuration has drifted. The app records nothing about who uses it.
When a customer says…
- “Half our bug reports arrive without steps to reproduce.”
- “Each issue type should start with its own description, and we do not want another custom field.”
- “Project admins should look after their own templates without raising a ticket with the Jira admin.”
- “Someone changed the create screen, and the template quietly stopped working.”
What it replaces
- A “how to write a good bug report” page nobody opens
- Descriptions pasted by hand from a wiki page
- Template setups that need extra custom fields on the create screen
Where it stops
-
Only Jira's Create dialog, opened from the
Create button or the
Ckey. Quick create on a board or backlog, email, Automation and the REST API do not open that dialog, and sub-tasks are never filled. - Summary, Description, Labels and Priority. Assignee, components and custom fields are left to the person.
- Software and business projects. Atlassian documents the Create dialog support it uses for those; service projects and Jira Product Discovery are not on that list and have not been tested.
- Automation may be enough. If filling a field after the issue has been created is good enough, an Automation rule on Issue created does that natively.
Evaluation
It cannot be installed from the Marketplace yet: the listing has been submitted and is awaiting Atlassian's approval. The documentation describes exactly what it does, so it can be checked against a customer's case now. Pricing, trial and resale follow on the listing once it is approved.
For the customer's security review
All three apps run on Atlassian Forge, and none declares egress, so app data has no address outside Atlassian to go to. It stays in the customer's Atlassian site: in the page, the request, or Forge storage. Eriksen Labs runs no servers for the apps and cannot read the data.
Permission scopes differ by app, and the security policy lists every scope with the reason for it. All of them are shown on Atlassian's install screen before anyone approves them.
Eriksen Labs holds no SOC 2 or ISO 27001 certification, and the security policy says so plainly.
- Mermaid Diagrams & Gantt
- No scopes
- Recurring Requests
- 5 scopes
- Issue Templates
- 6 scopes
When no app fits
Some gaps need a small extension of their own: a portal action, a panel, an extra step in a request flow, or a private Connect app that has to move to Forge. The Forge Extension Sprint is a fixed-scope, fixed-price build for that kind of gap.
Eriksen Labs builds the extension and hands over the source and documentation, so you are not left maintaining an internal Forge product forever. Your customer stays your customer.
From EUR 6,000 per one-week build, excluding any VAT. Solution Partners: ask for partner rates.
Forge Extension SprintContact
Email [email protected] with a few lines about the customer's situation: the product, what they are trying to do, and what they have tried natively. You get a straight answer on whether one of the apps fits, including when it does not. Replies normally come within two business days.
Support for an installed app goes through the support page as usual.
Eriksen Labs is a one-person Atlassian Marketplace vendor: Eriksen ENK, organisation number 937 027 834 in the Brønnøysund Register.