Information Security

Date of publication: 01 September 2021

Access Token

Flomatika will extract performance metrics from your Work Management system via their API. Access to this data will be strictly limited to client’s employees and Flomatika team members for the purposes of supporting the platform.

Data extracted does not include any confidential data (such as description, acceptance criteria, etc) with the fields extracted being explicitly described in Section 2. The list of fields can increase dependent on the level of additional analysis as requested by the client, such as:

  • how many extensions they want to enable
  • # of filters using custom fields

Data We Access and Store

Core fields:

  • Project Name
  • Project ID
  • AreaPath /  Filter ID
  • Work Item Type
  • Work Item State
  • Title (optional)
  • Assigned To (optional)
  • Created (date)
  • Activated (date)
  • Closed (date)
  • Updated (date) [including all changes/revisions/history of the issue]

Extended fields

  • The client, at their discretion, may decide to use extra ‘out of box’ and custom fields on the mapping process to allow custom filters and additional analysis.

Extraction Process

The Flomatika ETL (Extract Transform Load) Engine will be running according to the configuration described below to extract, transform, and load client’s data as described below:


  • Configurable how often (in minutes - default value: 5min) Flomatika ETL Engine will access client’s Work Management System’s API to fetch new data (defined in session 2).
  • The client can batch size how many data points Flomatika ETL Engine shall fetch at every access (default value: 500).
  • According to the configuration above, the Flomatika ETL Engine will fetch new data and make it available in a queue system to be transformed and loaded.


  • During the transformation, the data will be configured in a way to show relevant information and insights, with further mapping, configuration and normalisation being executed and stored into Flomatika Data Storage.
  • After the transformation, the Flomatika ETL Engine will make the data available in a queue system to be loaded.


  • The client Data is stored into Flomatika Data Storage (relational database service provided by Amazon called Aurora) using an exclusive partition and sort keys.

Flomatika SaaS Platform

Solution Architecture Design

  • Single page React webapp:
  • Deployed into AWS S3 (Sydney Region)
  • Distributed through AWS Cloudfront
  • Connects to Auth0 for authentication/authorisation
  • Connects to Flomatika api
  • Flomatika API:
  • Deployed as AWS Lambda Node.js functions (Sydney Region)
  • Served via AWS Gateway V2, using Auth0 token from client for verification
  • Flomatika Data:
  • Aurora relational database service storing raw data and configuration values
  • Flomatika ETL:
  • Deployed as AWS Lambda Node.js functions; (Sydney Region)
  • Not exposed externally
  • Functions are distributed/run via AWS SNS and Event scheduling
  • Access token for data sources kept using AWS Secrets Manager

User Interface

The Flomatika user interface has been developed as a single-page application based on the React framework. As such it is served as a static set of files from an AWS S3 bucket in the ap-southeast-2 region (Sydney), through AWS' globally deployed Content Delivery Network Cloudfront.

The Flomatika user interface itself has no user data and relies on Auth0 for user authentication, and the Flomatika API for interacting with the user's data.

For the purpose of configuring Flomatika for the organisation, the user would also have to be authenticated to the appropriate issue tracking data source (eg Jira, Azure Boards) and will have to have the appropriate access to pull data that would be used to link the Flomatika configuration to the equivalent data source entities. The user's authentication tokens for the data source are only kept in the user's browser and are not passed on to the Flomatika API, nor stored by Flomatika.


The Flomatika user interface itself is available to everyone. Login security is provided via Auth0's API, which provides the appropriate tokens that must be passed on to the Flomatika API for authorisation.

Access to the Flomatika app source can only be done via SSL calls. Any plain http call will be redirected to https. Only http and https ports are made available in Cloudfront.

The underlying S3 bucket has no direct public access, it serves its contents only via Cloudfront.
SSL certificates are provided to Cloudfront using its integration to AWS' Certificate Manager service.

Access to webapp assets is logged by Cloudfront.

MFA can be enabled via Auth0 if required.

Auth0 provides integration with Social and Enterprise security backends like Azure AD, Google Enterprise, as well as platforms that support LDAP and OpenID (eg Okta).

Roles and privileges for clients using an enterprise platform like Azure AD can be managed through Groups in the platform that can be mapped to Flomatika's Admin, Power, and Standard user roles.

Auth0 provides access logging for reporting.


The Flomatika implementation for its User Interface leverages AWS' approach to high availability.

Although the UI assets are stored in a single region (Sydney), AWS replicates those assets through a number of availability zones within the region.

Cloudfront is a global service and, as such, can be made available from any region and zone, should one of those become inaccessible.

The Flomatika API

The Flomatika API is executed through AWS' Lambda service. The API endpoints are accessed via AWS' Gateway V2 service.

Whilst the Gateway allows global access to the Flomatika API, the Lambda functions servicing the endpoints are deployed in AWS' Sydney region.

The Lambda code is written in Javascript and executes under Node.js 12.x.

API Security

Flomatika leverages the Gateway's integration with JWT providers (in our case Auth0) that verify the signature of the token passed from the calling client. This is the first pass at working out whether the user is a valid Flomatika user. Per JWT specification, the data passed in the token must match the signature. The token also has a limited lifetime and must be replaced by Auth0 regularly.

The context passed in the signed token includes the user's organisation, as well as the user's role and permissions within that organisation. These details are used by the Flomatika functions to ensure the correct data partition and rows are accessed.

Access to endpoints is only allowed via https, which is the only port available in this service. The SSL certificate is provided through the Gateway's integration to AWS' Certificate manager.

Communication between the Gateway and the Lambda functions leverages AWS' security model, which includes a secure transport.

High Availability

Flomatika leverages AWS' HA for the API Gateway which is a globally deployed service.

Lambda functions are deployed in the Sydney region but leverage AWS' multi-zone approach to availability.

Loading data from issue and project work tracking sources, aka Flomatika ETL

Data from the data sources is extracted, transformed, and loaded in an incremental fashion, based on the items' change date.

The whole process is executed via Lambda functions that respond to requests in AWS SNS queues.

The Lambda code is written in Javascript and executes under Node.js 12.x.

The ETL Lambdas are not deployed as part of the API set.

The security credentials used to access the data sources can only be accessed by those Lambdas that require them (those providing the Extract functionality). Those credentials are stored using AWS Secrets Manager service.

Data Storage

Flomatika data is stored in a relational database service provided by Amazon called Aurora.

Security tokens to access the data sources are kept separately using AWS' Secrets Manager.

AWS Simple Notification Service is used to temporarily hold data between the ETL services.

Access to Aurora database is only allowed via its own SSL-encrypted API. Aurora database encrypts its data at rest by default. AWS provides hardening and patching as part of its own operating model.

SNS server side encryption is turned on for all topics.

Flomatika Development

Flomatika currently uses GitLab to host its code base and execute CI/CD.

Only those members of the Flomatika team that have development or operational duties have write access to the Flomatika code base.

As part of our normal development processes we ensure all 3rd-party packages are upgraded regularly.

Flomatika Operations

The use of AWS Platform services like Cloudfront, Lambda, and the API Gateway allows the Flomatika team to leverage AWS' approach to security, patching, and availability which are best-of-breed.

Wherever possible we have used an Infrastructure-As-Code approach to deployment either through Terraform scripts, or through Serverless scripts when appropriate.
Only those members of the Flomatika team that have operational duties have access to the Flomatika AWS account.

CI/CD use a separate login not related to any Flomatika member. This login does not have access to the AWS console, and only has permissions that allow it to deploy Flomatika code.

User Notice

Terms of Use

Privacy Policy

Get Started

Shift to a Value Stream aligned organisation

Having near-realtime data you trust available at your fingertips has never easier with Flomatika’s Value Stream Management platform.
Flomatika Dashboard