Skip to content
LayaHelp Centre
laya.netOpen app
GuidesIntegrationsTroubleshootingContactlaya.netOpen app

SprintRetro Architecture Diagram and Data Flow

How SprintRetro is connected: where it runs, the data that moves, where it is kept and how it is protected, with a diagram to file with your security review.

Last updated

Print-optimised: choose “Save as PDF” in the dialogue
On this page

What this covers: SprintRetro on the Atlassian Marketplace (SprintRetro and SprintRetro Pro), as it works in its current release: where it runs, the data that moves and where it is kept. It is made by LayaNet LTD (company number 17430595), a company registered in England and Wales. On the Atlassian Marketplace it uses the vendor name Agile Pulse.

Last reviewed: 20 October 2026.

Architecture and data flow diagram

SprintRetro Architecture Diagram and Data FlowHow SprintRetro is connected: people use it inside their Atlassian site, where it runs on Atlassian Forge. It also uses the LayaNet service (London, UK; Stockholm, Sweden). Sub-processors outside Atlassian: OpenAI, KLIPY. The numbered list under the diagram says what each arrow carries.Inside yourAtlassian siteLayaNetservice(London, UK;Stockholm,Sweden)Sub-processorsOther webservices, notsub-processorsPeople in your JirasiteSigned in with theirAtlassian accountSprintRetroAn Atlassian Forge appJiraYour issuesYour data(database)MongoDB Atlas, onAmazon Web ServicesLondon (UK)Encrypted at restApplication serversAmazon Web ServicesStockholm (Sweden)Uploaded files andwhiteboard imagesAmazon S3, on AmazonWeb ServicesLondon (UK)Encrypted at restOpenAIAI featuresUnited StatesKLIPYGIF search in the browserUnited StatesPublic web servicesFile delivery networks,an emoji service andGoogle’s web servicesMiro or MuralOnly for people whoconnect oneProduct demoOnly if someone opensit123456789101112SprintRetro Architecture Diagram and Data FlowHow SprintRetro is connected: people use it inside their Atlassian site, where it runs on Atlassian Forge. It also uses the LayaNet service (London, UK; Stockholm, Sweden). Sub-processors outside Atlassian: OpenAI, KLIPY. The numbered list under the diagram says what each arrow carries.Inside your Atlassian siteLayaNet service (London, UK;Stockholm, Sweden)Sub-processorsOther web services, notsub-processorsPeople in your Jira siteSigned in with their AtlassianaccountSprintRetroAn Atlassian Forge appJiraYour issuesYour data (database)MongoDB Atlas, on Amazon WebServicesLondon (UK)Encrypted at restApplication serversAmazon Web ServicesStockholm (Sweden)Uploaded files and whiteboardimagesAmazon S3, on Amazon Web ServicesLondon (UK)Encrypted at restOpenAIAI featuresUnited StatesKLIPYGIF search in the browserUnited StatesPublic web servicesFile delivery networks, an emojiservice and Google’s web servicesMiro or MuralOnly for people who connect oneProduct demoOnly if someone opens it123456789101112
Used whenever the app is usedDashed: only in the cases its words giveNumber: the same number in the list below says what the arrow carriesShaded area: a boundary, named on it

In words

  1. People use SprintRetro inside Jira, signed in with their Atlassian account.
  2. SprintRetro reads from Jira as it works. In Jira: the issues people create from action items, when they choose to.
  3. The app’s Forge functions call our servers to run retros (cards, comments, votes, polls and action items) and to make AI requests. Sent over HTTPS (TLS).
  4. Only when someone sends a message from the in-app Contact us form: the person types a subject and a message, and the app adds the Jira site, the app version and their email address from their Atlassian profile, so we can reply; it asks for an address only when Jira does not share one. The message goes through the app to our servers, which email it to our support team through Amazon Web Services’ email service in Stockholm (Sweden). Our servers do not keep the message. Sent over HTTPS (TLS).
  5. The browser keeps a secure WebSocket open to our servers for live updates during a retro. Sent over Secure WebSocket (TLS).
  6. Our application servers keep your data in the database with MongoDB Atlas, on Amazon Web Services, in London (UK), and reach it over TLS. At rest, MongoDB Atlas encrypts the database’s storage and its backup snapshots, as it does for every cluster.
  7. Our application servers keep uploaded files and whiteboard images with Amazon S3, on Amazon Web Services, in London (UK). Uploaded files and whiteboard images are kept in Amazon S3 in London (UK), encrypted at rest, with public access blocked.
  8. Optional: only when someone uses an AI feature and AI is on for the site: our servers send OpenAI only the fields listed under How AI is used. Never sent to OpenAI: who wrote or voted for anything (no account ids, names, avatars or email addresses; anonymous cards are treated the same), and no Jira issue descriptions or Jira comments. OpenAI may keep a request for up to 30 days, solely to monitor for abuse, unless the law requires longer. We never store the prompt. Sent over HTTPS (TLS).
  9. Only when someone connects Miro or Mural to import a board: our servers reach that service with the connection the person made.
  10. Only when someone searches for a GIF: the browser sends the search words, and a random id kept in the browser, to KLIPY. Not your Atlassian identity. Sent over HTTPS (TLS).
  11. The browser loads public files from file delivery networks, an emoji service and Google’s web services. Our code sends no retro content to them.
  12. Only if someone opens the product demo: the browser shows it in a frame from the demo’s own service.

What is kept, where, and how it is protected

SprintRetro: the data kept, where, and how it is protected
DataWhere it is keptHow it is protected
Jira itself: the issues people create from action items, when they choose to.Inside your Atlassian site: JiraAtlassian’s own security controls. Atlassian describes them in its Trust Center.
Retros: name, board and sprint, settings, and who took part (Atlassian account ids and roles). Cards, comments, votes, polls, action items, ice breakers, sprint goals, health checks and whiteboard notes, with the account id of whoever added them. Comments also keep the author’s display name. Sprint Replay snapshots: Jira issue ids, keys and titles, status and story point changes, the sprint’s name and dates. AI results: sprint reports, replay stories, action quality scores and rewrites, Facilitator themes and suggestions (which can repeat a card’s text), and theme labels with their embeddings. Miro or Mural connections, only for people who connect one to import a board.LayaNet service: MongoDB Atlas, on Amazon Web Services, London (UK)All connections are encrypted: browsers and the app’s Forge functions reach our servers only over https and wss, and our servers reach the database over TLS, which MongoDB Atlas requires for every connection. At rest, MongoDB Atlas encrypts the database’s storage and its backup snapshots, as it does for every cluster. Uploaded files and whiteboard images are kept in Amazon S3 in London (UK), encrypted at rest, with public access blocked.
Uploaded files and whiteboard imagesLayaNet service: Amazon S3, on Amazon Web Services, London (UK)Uploaded files and whiteboard images are kept in Amazon S3 in London (UK), encrypted at rest, with public access blocked.

Never kept: Jira issue descriptions, Jira comments and attachments; email addresses; the prompts sent to OpenAI: each is built for one request and deleted straight after.

Retention and deletion

  • Uninstall: Nothing on our servers is deleted when the app is uninstalled: the app has no uninstall step.
  • Deletion: Deleting a retro or a card marks it deleted, and the record stays in our database. Nothing expires automatically.
  • Atlassian’s personal data reporting: The app does not use Atlassian’s personal data reporting yet, so a closed Atlassian account’s id, and the display name on its comments, stay in past retros.
  • Logs: Our servers keep their application log files for 3 days and their error log files for 14 days. Each request is also written, with its IP address, to the server’s console log, which is kept until it reaches a size limit rather than for a set number of days.

Sub-processors

Sub-processors that may process SprintRetro data
Sub-processorPurposeLocation
AtlassianRuns the app’s Forge functions, and Jira.Where your Atlassian site is hosted
MongoDB AtlasOur database service, on Amazon Web Services.London (UK)
Amazon Web ServicesHosts our application servers, and emails the messages sent from the in-app Contact us form to our support team.Stockholm (Sweden)
OpenAIAI features.United States
KLIPYGIF search in the browser.United States

About this document

  • This document is drawn from the same records as the SprintRetro trust page, and changes when they change.
  • Detailed network information is not published, to protect the service.
  • Questionnaire references: CAIQ v4 DSP-05 (data flow documentation) and DSP-19 (data location). These are references for your review, not a compliance claim.
  • Security contact: support@laya.net, with "Security report" in the subject line. Please never include passwords or tokens.
SprintRetro Architecture Diagram and Data Flow: change history
DateChange
20 October 2026First published.
Still stuck?

Email support@laya.net and include what you expected, what happened, and a link to the affected board or item so we can help quickly.

Contact support