# Introduction Welcome to Taloflow's documentation. ## Overview Taloflow is a **collaborative notebook** that helps teams generate detailed requirements and comparisons to evaluate technology product capabilities for specific use cases in any category in minutes. It combines: * a proprietary technology product data catalog curated by top analysts and AI; * an expert system for assessing and analyzing feature-functionality; and, * a notebook experience that provides visualizations and transparent insights as you go. It provides significant time savings, visibility, archiving, and accountability for the decision-making process. {% embed url="" %} # Getting Started Here's how to get a quick start with Taloflow. ## Setup ### Signing up You can [Sign up](https://use.taloflow.ai/signup) for a Taloflow account using email, or your Google, Microsoft or GitHub account. ### Dashboard Once in the dashboard, you'll be able to start creating the evaluations mentioned above by clicking the "Create evaluation" button. ### Creating an Evaluation Once you've clicked "Create new evaluation" from the Dashboard, you'll be asked: 1. to select the Category you want to run an evaluation for; and 2. to combination of use cases you want to use {% hint style="info" %} Use cases are fully adjustable, so choose any number that may be relevant from the available list. {% endhint %} After a few seconds, you'll have an evaluation ready-made for you to work with. ### Using the Evaluation The evaluation comes in the form of a collaborative text editor with lots of smart blocks that you can add, toggle, and configure to suit your reporting needs or provide new insights into your decision. You can go to the Tables view, which allows you to prioritize your requirements, features and weight dimensions manually to your liking, and add or remove products. {% hint style="info" %} You can switch back and forth between the Report and Tables view at your leisure. {% endhint %} # How it Works Here's a high level overview of the logic behind Taloflow evaluations. ## How the Evaluation works The Evaluation is comprised of configurable features and requirements tables, scores (and rankings) for products, and a collaborative text editor experience to help you whittle down requirements and features, and various types of blocks to show the data. ### Product Scores All products are rated on all Requirements, Dimensions, and Features. {% hint style="info" %} Features are the components that make up Requirements and Dimensions. For example, a Requirement like "Must integrate with our current stack" could include Okta integration and PagerDuty integration as features, and any number of individual Features can map one-to-many to Dimensions. {% endhint %} Requirements and Features have 4 possible priority settings: 1. Critical 2. Important 3. Nice To Have 4. Don't Care
Products can have the following ratings for Requirements and Features: 1. Great 2. Good 3. OK 4. Poor 5. N/A The weights assigned to Dimensions (e.g., Integration) also impact the overall product scores.
### Product Ranking The product ranking is a simple order of the products based on their score plus using Critical-rated features as a threshold function. You may get a product ranked higher despite having a lower score due to this.
### Impact Impact tables and charts are calculated by looking at the standard deviation. You may have 5 features that are Critical but have every product rated the same, whereas 5 features that are Nice To Have could show a lot of variance between products, in which case the Nice To Have's have more Impact.
# Category Curation This post covers the data sources, curation process for Taloflow categories. ### Underlying Data Sources Taloflow aggregates data from reputable and transparent sources tailored to the type of feature being assessed. These sources include: * **Industry Analysts:** Taloflow collaborates with subject-matter experts with backgrounds at firms like Gartner or strong independent reputations. Examples: * Abhishek Singh – Data Connectivity & Integration * Ravisha Chugh – Security & Compliance * Bernd Harzog – Observability & APM * Rohit Khare – Identity & Authorization * Anjul Sahu – Platform Engineering & Dev Platforms * **Trust Centers:** API-based access to vendor trust centers for compliance and security data (e.g., certifications like SOC 2 Type 2). * **Data Partnerships:** A unique partnership with Sacra provides private market intelligence to evaluate vendor quality, innovation, and growth potential. * **Vendor Materials:** Through cooperation agreements, Taloflow accesses internal documentation, manuals, and RFP templates not publicly available. * **User Reviews & Documentation:** Prioritizes recent, high-signal user reviews, release notes, and product guides—typically no more than 24 months old. * **LLM-Generated Insights:** Taloflow uses multiple large language models (OpenAI, Claude, Gemini, etc.) to analyze public data, summarize sentiment, and extract useful observations. {% hint style="info" %} For standardized features like SOC 2 compliance, ratings tend to converge. Taloflow minimizes skew by prompting LLMs to normalize inputs while retaining differences in performance or nuance where meaningful. {% endhint %} *** ### Category Curation Taloflow’s category and feature definition process is both AI-driven and expert-led: 1. **Category Creation:** Based on some initial prompts usually provided by experts or users Taloflow uses a generalized LLM to flush out category basics such as products and demanded features. The initial prompts provide context, suggested vendors and other factors to ensure a cohesive category is created. The initial results are then reviewed by Taloflow experts to ensure that the category has captured the key vendors and features. 2. **Initial Feature Matrix:** LLMs propose an initial feature lists and classifications. This list is expert reviewed and modified as needed. This pass is based upon prompts developed by Taloflow over the last several years and is structured to ensure good results. 3. **AI Deep Research:** A deep research pass is run on a feature by feature basis. Agents gather relevant sources and generate rating justifications, including confidence levels. 4. **Confidence Thresholding:** If confidence is too low (due to weak, outdated, or missing sources), a manual QA process is triggered. The QA process could include additional deep research, contacting vendors directly, uploading additional context documents, etc. 5. **Analyst Validation:** Analysts may join vendor demos, speak with customers or peers, or apply their judgment to complete or improve the ratings. *** ### Feature Ratings Each product is evaluated using two core input types: * **Facts:** Objective attributes (e.g., founding year, HQ location, market reach) that are relevant to, but not used by the rating system. * **Opinions:** Qualitative evaluations of how well a product fulfills a given functionality. Taloflow’s AI process includes: * Broad web search across multiple platforms * Multiple LLM queries for triangulating consensus * Confidence scoring and source attribution per cell in the UI After the AI pass, industry analysts review and adjust the ratings using their expertise and the AI-provided signals. Each feature-product pair is rated across multiple dimensions: * **Absolute:** The raw capability of the product * **Normative:** Conformance with industry standards * **Relative:** Performance versus peers These are synthesized into a final score that maps to Taloflow’s standardized rating scale (e.g., Great, Good, OK, Poor, NA, Unknown). {% hint style="info" %} You can click any cell in the feature table and the "By Taloflow" widget to view Taloflow’s justification and source information. {% endhint %} A final pass is made through the ratings to eliminate duplicate or highly correlated features that don’t add any value to the analysis. *** ### Use Case Configuration Taloflow’s use cases reflect real-world experiential knowledge, typically shaped by input from industry analysts. They guide which features are considered Critical, Important, or Nice to Have within specific buyer journeys or evaluation goals. *** ### Data Freshness and Review Triggers Taloflow regularly updates its datasets and has monitoring systems in place to: * Detect anomalies in aggregate feature ratings * Flag potential degradation in data quality * Trigger re-evaluation workflows by industry analysts
# Scores and Ranking This post covers the scoring and ranking mechanisms for Taloflow evaluations. ### Score and Ranking Calculations #### Feature Scores Each product receives an average Feature Score, calculated using: * Weighted feature ratings (e.g., Great ≈ 3.8× impact of Poor, Good ≈ 3.4×, OK ≈ 2.6×) * Priority weights (Critical ≈ 5×, Important ≈ 4× compared to Nice to Have) Users can override these values by customizing weighting schemes. #### Requirement & Dimension Scores * Calculated in the same manner, but in the case of Dimensions use weights (\~/100) instead of priorities * Aggregated based on their underlying features (unless overridden) {% embed url="" %} A composite score is then calculated as the average of: * Feature Score * Requirement Score * Dimension Score #### Ranking Heuristic Products are ranked using a tiered filtering system: 1. Products that meet all Critical and Important features are ranked first. 2. Then, products that meet all Important, but not all Critical, features. 3. Finally, remaining products. This enforces threshold logic: * Products missing a Critical feature cannot outrank any product that satisfies all Critical features, even if their average score is higher. * The same logic applies to Important features relative to both Critical and Nice to Have. *** ### Dimensions and Requirements as Aggregates * Features are the atomic units of the evaluation. * Requirements and Dimensions are not scored directly; they aggregate the weighted scores of associated features. * Any changes to feature ratings or priorities will propagate upward to affect related requirement and dimension scores. {% hint style="info" %} In the Tables tab, you can customize use case priorities, override feature scores, or directly edit dimension/requirement scores. {% endhint %} # Selecting Use Cases In this tutorial, you'll learn how to select and use categories and use cases effectively to start an evaluation. {% embed url="" %} **Step 1:** Begin by selecting a category. This will present you with a variety of use cases. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/15789d3d-950b-4644-8aac-8241b15a9aea/3799e47d-aa8a-42cd-be16-edae3a76f315/images/24d79323-28ca-47d4-9179-b499a0738758.png) **Step 2:** Understand that these use cases are essentially presets. They come with a set of features that have been assigned different priorities like critical, important, or nice to have. Each priority has its own weight. {% hint style="info" %} If your assessment requires all use cases, simply select 'all' at the top. This action will select all use cases for you. {% endhint %} It's designed to provide a useful starting point when you start an evaluation. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/15789d3d-950b-4644-8aac-8241b15a9aea/3799e47d-aa8a-42cd-be16-edae3a76f315/images/80f4bc9c-361c-4d33-8fd7-d06c60b7661e.png) # New Category Request In this article, you'll learn how to create a new evaluation category and define its parameters. {% embed url="" %} **Step 1:** Navigate to the **Create Evaluation** screen. Here, you'll find a button to request a new category.
Image
**Step 2:** Provide details about the new category. This includes how you define the category, the vendors you want included, the use cases, and who should have access to this project.
Image
**Step 3:** Give your category a name.
Image
**Step 4:** List the products you think should be considered for this category. This helps us understand the cluster of vendors that must be included and which other vendors should be considered.
Image
**Step 5:** Provide some use cases and upload any reference materials like RFPs, manuals, slides, etc. to guide our research. **Step 6:** Decide whether you want a workspace created for this project. If you do, provide a name for it.
Image
**Step 7:** Optionally, you can provide a project code, identify an owner, and list any other individuals who should have access to the support. **Step 8:** Indicate your preferred turnaround time, whether it's two business days or five business days. **Step 9:** Add any additional comments that would help us prepare this for you in the best possible way. **Step 10:** Click **Submit** and you'll be notified via email when the category is ready.
Image
f # Reports View This article will guide you through the different sections of the evaluation report view, helping you understand how to interpret the scoring chart, conclusions block, product score calculation, etc. {% embed url="" %} ### Scoring Chart The scoring chart categorizes products based on their ability to meet critical and important feature criteria. It also ranks vendors within these categories by score. Note that a vendor with a higher score may rank lower if it doesn't meet all critical features. {% hint style="warning" %} **The "Sync data"** toggle to the right of most sections allows you to limit the impacts of changes to your assumptions on the report view. You can choose to turn this off or on, depending on whether you want the report view to sync with the tables view. {% endhint %} ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/f45d3239-8383-489c-9849-fd18dff3fb4a/eef103fc-0e2d-4ee1-be6d-00dc68b795a5/images/9f0244ae-94f9-418b-9c3a-83978dca3ac7.png) ### Conclusions Block This section identifies the winner and runner-up, explaining why the winner outperformed the runner-up. It breaks down the key dimensions and trade-offs at the requirements and features level, helping you understand the basis of the recommendation. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/f45d3239-8383-489c-9849-fd18dff3fb4a/eef103fc-0e2d-4ee1-be6d-00dc68b795a5/images/0072659b-2df5-41f3-8110-45f539468774.png) Continue down, and you can explore the detailed product rankings. You'll find an explanation for each product's ranking. {% hint style="info" %} Toggle to see more products if needed. {% endhint %} ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/f45d3239-8383-489c-9849-fd18dff3fb4a/eef103fc-0e2d-4ee1-be6d-00dc68b795a5/images/5a229c4c-6026-4bb3-b1d1-353846906343.png) This sections below explain how the Future Score, Dimension score, and Requirement score work together to produce an average score, which is then used to rank vendors. This Product Features Fails table shows how many critical, important, or nice-to-have features each product failed. It helps you see the key differences between vendors. ### Impact Visualizations and Tables These sections break down which dimensions had the most significant impact on the overall scores and rankings. You can toggle and compare different vendors to understand the trade-offs. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/f45d3239-8383-489c-9849-fd18dff3fb4a/eef103fc-0e2d-4ee1-be6d-00dc68b795a5/images/151a69cd-8d81-4fbc-b33a-2adda2aa5d56.png) ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/f45d3239-8383-489c-9849-fd18dff3fb4a/eef103fc-0e2d-4ee1-be6d-00dc68b795a5/images/54744213-6f76-4796-8ff3-9bb34f2d42e3.png) Drill into similar charts at the requirements level and the features level. For instance, you might find that a specific feature, like language detection, made a significant difference between two vendors. ### Methodology Section The methodology section explains how the different components contribute to the final score and rank. It also lists the products included in the evaluation. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/f45d3239-8383-489c-9849-fd18dff3fb4a/eef103fc-0e2d-4ee1-be6d-00dc68b795a5/images/289b0c77-46da-468b-b845-c61ee86f3806.png) ### Renaming the Evaluation Finally, know that you have the option to rename your evaluation within the report view. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/f45d3239-8383-489c-9849-fd18dff3fb4a/eef103fc-0e2d-4ee1-be6d-00dc68b795a5/images/cf4d668f-eed1-41a2-b048-36215dce1169.png) # Tables View Get ready to take control of your product evaluation using the Tables view. By following this tutorial, you'll learn how to adjust key assumptions and manage products, features, dimensions, etc. {% embed url="" %} ### Tables View You'll see four main tables once you've toggled to the Tables view: Products, Features, Dimensions, and Requirements.
{% hint style="info" %} **Get a better view of things:** * **Collapse the sidebar** for easier navigation. * Use the **expand** button for a broader view of your tables. * **Pin important columns** for quick access. * **Apply column filters** to focus on the datasets that matter. * **Use the table search bar** to quickly locate any item or value across Products, Features, Dimensions, or Requirements. {% endhint %} ### Products Table The Products Table has lots of data related to the products and vendors associated with the evaluation, including growth rates, launch dates, and key customers.
Click **Add Product** to include another product in your analysis. Fill out the details as prompted.
Click the **trash icon** beside any product you want to remove.
### Features Table Features drive your evaluation. They impact both dimensions and requirements.
Use the **priority** column to rank features according to your criteria.
**Add new features or delete existing ones** as your evaluation evolves. The table also showcases scores, opinions, and data sources.
Dive deeper into a feature to see its ratings, sources, and additional details.
You can overwrite any Taloflow-provided rating and give your own rationale. Click the score to edit, then add your reason.
Click the gray pill to see which sources Taloflow used for a given score or opinion.
### Dimensions Table Treat dimensions as your highest-level criteria. Assign more weight to crucial items like **Integration**. The weights adjust automatically to keep totals balanced.
{% hint style="info" %} Scores in this table are computed from underlying features and product differentiators, not by an analyst or AI. Override scores manually if needed. {% endhint %} ### Requirements Tables Requirements combine various features, and you can adjust them as needed for security, compliance, or any other criteria. Remove or add features, and reprioritize requirements directly.
Override requirement scores as situations change.
By following these steps, you’ll harness all the power of the Tables view to precisely manage and evaluate your options. # Real-time Collaboration Taloflow makes it easy for teams to collaborate on evaluations and documentation. This guide walks you through Taloflow’s core collaborative features, explaining when and how to use each. {% embed url="" %} ### Inviting Teammates Invite colleagues to join your workspace or participate in a specific evaluation. Use the **Share** option to add new collaborators to an evaluation. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/cbeec087-f515-4beb-910f-6afce30a9e69/dff082f3-e1b8-47ef-a1f2-9b22bfa87d2d/images/ccbc6cae-83f8-4e0d-9f83-7fd26b23d120.png) ### Collaboration Tools Taloflow supports rich collaboration by letting users comment, edit, and format text together. Team members can see each other’s changes in real time, making it easy to co-author documents or evaluations. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/cbeec087-f515-4beb-910f-6afce30a9e69/dff082f3-e1b8-47ef-a1f2-9b22bfa87d2d/images/f046f9ed-add5-433a-bcf0-f721ba40b828.png) ### Referencing Products and Features To provide additional context to discussions or documentation, use the slash (/) command to reference specific products, features, requirements, or dimensions from your evaluation. This links information effectively and keeps everything connected within the workspace. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/cbeec087-f515-4beb-910f-6afce30a9e69/dff082f3-e1b8-47ef-a1f2-9b22bfa87d2d/images/0d972f1a-c044-4377-96e5-036f444230c4.png) ### Formatting Options Taloflow offers various formatting tools to improve readability and communication. Use these tools to apply headings, bold text, lists, or add code snippets directly into your content when discussing technical details. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/cbeec087-f515-4beb-910f-6afce30a9e69/dff082f3-e1b8-47ef-a1f2-9b22bfa87d2d/images/f47ec135-8bb2-4d7a-a15d-adf2f9331bc3.png) # Change Log In this article, you'll learn how to make changes to your evaluation in the Tables view and ensure full traceability of your actions. {% embed url="" %} Start by making changes to your evaluation in the Tables view, like making changes by altering priorities.
Image
Notice that all these details are automatically saved to the changelog. This provides full traceability of what occurred while building up the use case for the report.
Image
{% hint style="info" %} If you forget to add a reason to the changelog, simply click **Add Reason** on any of the change bubbles. {% endhint %}
Image
# Workspace Management Switching and managing workspaces in Taloflow makes organizing your team's work efficient. This guide walks through the key workspace features, supported by visuals to show where to find each function {% embed url="" %} ### Navigating Workspaces Taloflow's interface makes it easy to switch between multiple workspaces. The main dashboard displays available workspaces, allowing seamless transitions to the one needed at any time. ### Workspace Management Overview Access the **Manage workspace** page to review essential workspace details. Here, you'll find the workspace name, associated project code or ID, and the workspace ID used for support or integration needs. These details are all available in the workspace settings pane. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/09e94e6a-37a5-4d69-b123-e8a42c696f91/b3fff77c-de7d-4d9e-ad15-c00a5ca8cec7/images/e0521875-9db3-4f29-bf02-ddb6c68dff09.png) ### Organizing with Parent and Child Workspaces Taloflow allows you to structure workspaces hierarchically by setting parent workspaces. This lets you create a logical organization where some workspaces inherit properties or access from larger, parent workspaces. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/09e94e6a-37a5-4d69-b123-e8a42c696f91/b3fff77c-de7d-4d9e-ad15-c00a5ca8cec7/images/80ded4d0-bfb2-4a4d-8a9b-7eb07aa08f9a.png) Use this structure for teams working across multiple projects or departments, making permission management straightforward and scalable. ### Managing Members and Permissions Within the member management area, admins can see all members and their roles. Taloflow defines three primary roles: \- **Viewer:** Can view all evaluations in the workspace \- **Editor:** Can create and edit evaluations \- **Admin:** Can invite and manage members, adjust roles, and control workspace settings The member management panel lets you assign or change these roles easily according to each collaborator's responsibilities. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/09e94e6a-37a5-4d69-b123-e8a42c696f91/b3fff77c-de7d-4d9e-ad15-c00a5ca8cec7/images/71410560-91d7-4c85-9333-5d5fca1fae8d.png) {% hint style="info" %} Workspace owners inherit admin capabilities and are highlighted in the member list. {% endhint %} ### Creating Child Workspaces To further organize your projects, create new child workspaces nested within parent workspaces. {% hint style="warning" %} Admins in a Parent workspace can view and manage Child workspaces. {% endhint %} ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/09e94e6a-37a5-4d69-b123-e8a42c696f91/b3fff77c-de7d-4d9e-ad15-c00a5ca8cec7/images/9181e277-aa7f-4186-aebe-8ee5d437129d.png) ### Finding Key Workspace Details In need of support or setup information? The workspace ID and other relevant details are displayed prominently on the workspace overview, so you have what you need right where you expect to find it. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/09e94e6a-37a5-4d69-b123-e8a42c696f91/b3fff77c-de7d-4d9e-ad15-c00a5ca8cec7/images/17592e1f-c392-4861-82e9-ecab07f23ad6.png) With these features, managing your teams and projects in Taloflow stays streamlined and transparent, no matter how your organization grows. # Evaluation Management Explore how to manage your evaluations efficiently—from viewing and sharing to archiving and deleting—using the platform's evaluation management features. ### Overview of Evaluation Management Stay on top of your workspace and shared evaluations with streamlined tools tailored for collaboration and control. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/44a9d0f7-5e0d-4da2-8d3e-ede4cc6f052d/69f162cb-ee48-4a43-a013-04ba9566acd5/images/220f24be-8aa0-4ce5-86ec-e9ca0b38785b.png) The **My Evaluations** section displays all evaluations you have access to—whether they're tied to a workspace you're in or owned by you. It's the central hub to quickly locate any ongoing or completed evaluation projects. #### Shared Evaluations If colleagues have shared evaluations outside your primary workspace, these appear under the **Shared Evaluations** tab, keeping everything accessible but organized separately. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/44a9d0f7-5e0d-4da2-8d3e-ede4cc6f052d/69f162cb-ee48-4a43-a013-04ba9566acd5/images/4c7e55d9-c02f-44e6-a79d-3a54977ac366.png) ### Renaming and Sharing Evaluations * Customize and communicate efficiently by renaming evaluations and easily sharing them with your team. * To rename an evaluation, ensure you have at least editor permissions, then select **Rename** in the options menu (**three dots**). This keeps names clear and relevant as projects evolve. * Copy an evaluation link directly from the menu and share it with colleagues for quick access and collaboration. ### Archiving Evaluations Organize your workspace by archiving evaluations when they’re no longer active. Archived evaluations move to the **Archive** tab for simple retrieval if needed later. ![](https://usercontent.us.prod.clueso.io/6f46ef8a-0cac-48dd-b715-7c165eddda1e/44a9d0f7-5e0d-4da2-8d3e-ede4cc6f052d/69f162cb-ee48-4a43-a013-04ba9566acd5/images/9d179a1c-05fa-43cc-884a-81aae0099aed.png) You can also unarchive evaluations in the Archived tab in a few clicks (**three dots)**, returning them to active status for further action. ### Deleting Evaluations Finished with a project and don't want it anymore? You can delete the evaluation. Access this option in the context menu, confirm your choice, and the item will be removed within seconds. ### Versioning and In-Evaluation Controls Keep your work organized by creating evaluation versions as you make progress. All menu controls—including rename, copy link, archive, and delete—are available at the top of each evaluation for convenience. # Collaboration Architecture Taloflow's real-time collaboration is built on CRDTs (Conflict-free Replicated Data Types) via Y-WebSocket. This means multiple users can edit an evaluation simultaneously and their changes will always converge to a consistent state — with no merge conflicts and no data loss. ## What Is a CRDT? A CRDT (Conflict-free Replicated Data Type) is a data structure specifically designed so that concurrent edits from multiple clients can always be merged automatically and deterministically. Unlike traditional operational transformation or "last write wins" strategies, CRDTs preserve every edit and reconcile them through mathematical guarantees rather than server-side arbitration. {% hint style="info" %} CRDTs are the same underlying approach used by Figma and Notion for their real-time collaboration models. The key property is convergence: regardless of network latency or the order edits arrive, every client will eventually reach the same state. {% endhint %} ## Architecture Overview ``` User Browser A User Browser B | | | wss:// (TLS) | wss:// (TLS) v v +---------------------------+ | Y-WebSocket Server | | - Receives CRDT updates | | - Broadcasts to peers | | - Persists to Redis | +---------------------------+ | | HTTP POST (changes only) v +---------------------------+ | Eval-Update Lambda | | - Writes DB delta | | - Stores S3 snapshot | | (encrypted, SSE-C) | +---------------------------+ | PostgreSQL + S3 ``` ### Component Responsibilities | Component | Role | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Y-WebSocket Server** | Receives CRDT update messages from connected browsers, broadcasts them to all peers in the session, and persists live state to Redis | | **Redis** | Holds the authoritative in-memory CRDT state for active collaboration sessions | | **Eval-Update Lambda** | Receives change notifications via HTTP POST, writes a structured delta to PostgreSQL, and periodically stores an encrypted full-document snapshot to S3 | | **PostgreSQL** | Stores evaluation metadata, structure, and deltas as durable relational records | | **S3** | Stores encrypted full-document snapshots for point-in-time recovery | ## Privacy Design of the Collaboration Layer {% hint style="warning" %} Evaluation payloads contain product assessments and feature data. They do not contain user PII. Identity within the collaboration layer is handled exclusively through anonymous UUIDs. {% endhint %} ### Transport Security All WebSocket connections use `wss://` — WebSocket Secure over TLS. Unencrypted WebSocket connections (`ws://`) are not permitted. ### Identity Within the Collaboration Layer * All change attribution within an evaluation uses `member_id` (UUID) only. * Email addresses, display names, and other PII are never embedded in CRDT update messages. * Services that do not require user identity (evaluation resolver, catalog resolver) never receive PII. ### Application-Level Encryption for Snapshots S3 snapshots are encrypted at two layers: 1. **Application layer**: The evaluation document is gzip-compressed, base64-encoded, and AES-encrypted before being written to S3. 2. **Server-side encryption**: S3 applies SSE-C (Server-Side Encryption with Customer-Provided Keys) as an additional layer. ### Lambda Data Isolation The eval-update Lambda includes a `doNotProcessUpdates` flag that prevents the Lambda from re-ingesting its own output. This eliminates feedback loops in which a Lambda-written change triggers a new CRDT update, which triggers another Lambda invocation. ## What Is Persisted and When | Data | Storage | Timing | | --------------------------------------- | -------------- | ------------------------------------------------- | | Live CRDT state | Redis | Continuously, during active collaboration session | | Evaluation delta (structure + metadata) | PostgreSQL | On each change, written by eval-update Lambda | | Full-document snapshot | S3 (encrypted) | Periodically, triggered by eval-update Lambda | {% hint style="info" %} Redis state is ephemeral by design — it holds only the data needed for active sessions. PostgreSQL and S3 are the durable records of truth. {% endhint %} ## Multi-User Scenarios ### Two users edit the same section simultaneously Each browser generates a CRDT update locally and transmits it to the Y-WebSocket server. The server broadcasts both updates to all connected peers. Each client applies the remote update to its local CRDT. Because CRDTs are mathematically guaranteed to converge, both clients reach the same final state regardless of which update arrived first. No conflict dialog is shown; no data is lost. ### A user disconnects and reconnects On reconnection, the Y-WebSocket server sends the client the full current CRDT state from Redis. If the Redis state has been evicted (session expired), the Lambda retrieves the most recent S3 snapshot, decrypts it, and restores the session state before reconnecting the client. ### A workspace with 50 concurrent editors Y-WebSocket broadcasts updates as compact binary CRDT diff messages, not full document copies. Message size scales with the change, not the document size, so 50 concurrent editors produce 50 small diff broadcasts per change — not 50 full-document transmissions. Redis holds a single authoritative state object regardless of the number of connected clients. # Export to PDF In this article, you'll learn how to export a report from the report view. This feature is useful when you need to share a nicely styled PDF of the report with your stakeholders. **Step 1:** Navigate to the report view. **Step 2:** Click on the three dots.
Image
‍**Step 3:** Select **Download Report**.
Image
**Step 4:** Wait for the PDF to generate. This may take a few seconds. **Step 5:** Once the PDF is generated, open it to view the report. You'll find a well-formatted PDF ready for sharing with your stakeholders. # Export to Excel Quickly export your table's data to Excel by following these clear, step-by-step instructions. You'll end up with a fully formatted Excel file, organized just like the data you see in your Tables tab. {% embed url="" %} Step 1: Go to the **Tables** tab to view your existing tables.
Image
Step 2: Click the **three dots** menu in the upper right corner of the interface to reveal more options.
Image
Step 3: Select **Download Tables** from the dropdown menu to start the export process.
Image
Step 4: Open the downloaded Excel file. The spreadsheet contains multiple tabs: Requirements, Dimensions, Features, and Products—matching the categories present in your evaluation.
Image
Some columns, such as Reasons, Sources, and References in the Features tab, may be hidden due to the detailed data displayed. To see these hidden columns, simply unhide them within Excel.
Image
By completing these steps, you're ready to work with all your exported data directly in Excel, organized just as it appears in the product interface. # Security Overview High-level summary of Taloflow security controls and where to find details. ### Security overview Taloflow is designed to protect customer evaluation data. Controls follow least privilege and defense in depth. ### Core controls * **Authentication** is handled through Auth0. See [Authentication & Access Control](/security/platform-controls/authentication-and-access-control). * **Authorization** is enforced centrally via policy. See [Authorization & Permissions](/security/platform-controls/authorization-and-permissions). * **Encryption** is used in transit and supported at rest. See [Encryption Standards](/security/platform-controls/encryption). * **Auditability** is supported via request-level logging. See [Logs, Audit Logs, and Backups](/security/platform-controls/logs-audit-logs-and-backups). * **Tenant isolation** is part of platform design. See [Tenant & Environment Isolation](/security/platform-controls/tenant-and-environment-isolation). * **Resilience** is addressed through backups and recovery practices. See [Availability & Continuity](/security/security-operations/availability-and-continuity) and [Disaster Recovery](/security/security-operations/disaster-recovery). * **Payments** are processed by Stripe. See [Payment Security](/security/trust-and-governance/payment-security). ### Compliance Certification status and audit updates live in [Compliance & Certifications](/security/trust-and-governance/compliance-and-certifications). ### Security questions Send vendor security questionnaires and document requests through the [Support Hub](broken://spaces/-MQkUmzRViVxDERN9vKk/pages/7w2btLpaU63hhnW4Dd7q). # Platform Controls Identity, encryption, logging, isolation, and data retention controls. Core security controls for the Taloflow platform. These pages focus on implementation and system behavior. If you’re looking for org policies and compliance status, see [Trust & Governance](/security/trust-and-governance). ### Pages in this section * [Authentication & Access Control](/security/platform-controls/authentication-and-access-control) * [Authorization & Permissions](/security/platform-controls/authorization-and-permissions) * [Encryption Standards](/security/platform-controls/encryption) * [Secrets Management](/security/platform-controls/secrets-management) * [Logs, Audit Logs, and Backups](/security/platform-controls/logs-audit-logs-and-backups) * [Tenant & Environment Isolation](/security/platform-controls/tenant-and-environment-isolation) * [Evaluation Data Retention](/security/platform-controls/evaluation-data-retention) # Authentication & Access Control How Taloflow authenticates users and services, and manages tokens. ### Zero Trust Architecture Taloflow implements a zero-trust security model where all requests require explicit authentication and authorization: * **All API requests** require either machine-to-machine (M2M) tokens or user authentication tokens * **Token scoping**: Each token is limited to specific permissions and has defined expiration times * **Service-to-service authentication**: Managed through Open Policy Agent (OPA) * **JWT verification**: Requests are verified using signed JSON Web Tokens (JWTs) ### Open Policy Agent (OPA) Implementation We use OPA (see [Authorization & Permissions](/security/platform-controls/authorization-and-permissions)) as our centralized authorization system for all API requests: * **Scope-based access control**: Every request is evaluated against token scopes and user permissions * **Service identity verification**: All services must prove their identity before accessing resources * **Request authorization flow**: Each API call passes through OPA evaluation before reaching application logic * **Centralized policy management**: Authorization rules are maintained in a single, auditable location ### Failed Authentication Handling Taloflow follows security best practices for authentication failures: * **Auth0-managed responses**: All authentication is handled through Auth0's secure infrastructure * **Standard error messages**: Failed authentication attempts receive generic error messages that do not disclose information about valid usernames or account details * **Silent failure patterns**: Security-sensitive operations fail without revealing the reason for failure to potential attackers * **Separate error handling**: API authentication errors are handled differently from UI authentication to optimize both security and user experience ### Token Lifecycle Management * **Token expiration**: All tokens have defined expiration periods * **Scope enforcement**: Tokens can only perform actions within their designated scope * **Internal token generation**: Services can generate internal tokens with revised scopes for specific operations * **Audit logging**: All token usage is logged with JTI (JWT ID), User ID, thumbprint, and expiration time ### Credential handling Taloflow does not store user passwords in human-readable form. User authentication and credential storage are handled by Auth0. # Authorization & Permissions This document covers the extensive and robust permissioning capabilities available within the Taloflow platform for customized access and control schemes. ### Overview Taloflow provides robust permission and security features, offering fine-grained permissions for implementing Role-Based Access Control (RBAC) and customized access and control schemes. The permissions and security components include user authentication through Auth0, centralized authentication verification via an Open Policy Agent (OPA) server, and separate authorization for every API request through OPA. The system enforces the process using encrypted JWT tokens and a common library across the Taloflow codebase. External requests are first provided with an Auth0 token, which the system verifies. Then, an internal token with revised scopes is provided for the requested action. Services within the system use this internal token and their service identity to verify that the request is within the scope of permissions. Taloflow's permission system is highly flexible, allowing for a wide range of permissioning structures, including placing users into groups, attaching permissions at both group and user levels, and restricting access at the resource level. Additionally, the system enables the implementation of data filtering when necessary and requires proper authorization tokens of the service and the user for any request authentication. ### Permission System Implementation The Taloflow permission system consists of the following components: 1. **Policy Database:** Policies are attached to principals and resources through their IDs. A policy contains: * An action (allow or deny) * A list of principals * A list of resources * A set of conditions 2. **Rego Rules:** Rules written in Rego enforce the policies. 3. **OPA Server Implementation:** The OPA server provides a fast and efficient way to analyze the rules database. It communicates with the rest of the system to obtain information about resources and principals. 4. **Security Libraries:** Libraries enforce security mechanisms at the server level, generally as transparent middleware to the developer, reducing the chance of developer error.
### Key Points of the Permission System * **User Data Security:** User information is safely stored in Auth0. Taloflow does not use passwords, email addresses, or other personal information in the permissioning process. * **Mandatory Authentication:** All user requests on every server and to every API must be accompanied by a verifiable, encrypted token. While not technically "zero trust," the assumption is that no communication, even behind the firewall, can happen without some trust element in the request. * **Centralized Authentication and Authorization:** All decisions are centralized into a set of OPA servers. This ensures consistent permissions and minimizes timing differences and developer errors. Scopes are consistently granted, and the risk of a centralized failure is considered worth the benefit of consistent decision-making. * **Flexible Rego Rules:** Rego offers the ability to create flexible rules that can be easily updated. Centralized permissioning means services do not need to implement specific rules, as actions are impacted directly in OPA with ALLOW or DENY returns. This enables responsiveness to individual security needs. * **Granular Authorization:** Requests can be authorized at almost any level in the system. While most authorization currently happens at the API level, method-level or even within-method-level authorization can be easily implemented. This allows for restrictions on specific data entries or other low-level information if necessary. ### Permissioning Logic Implications Taloflow's permissions system is very flexible and allows for a wide range of permissioning structures: * **User Groups:** Users can be placed into groups. In addition to Taloflow's standard role groups, custom groups can be established. Permissions are attached to both groups and users, allowing limitations or grants at both levels. Taloflow offers Admin and Member role groups for workspaces and Owner, Editor, and Viewer roles for evaluations, supporting a traditional RBAC scheme. * **Fine-grained Permissions:** Every API call in the system is authorized through OPA, allowing for data filtering when needed. * **Security Against Bad Actors:** OPA authenticates any request it receives to verify that the sender is authorized. For any bad actor to succeed, the service and the user must have a proper authorization token. ### Policy Evaluation Logic Taloflow assumes that all requests are DENIED unless a rule allows them. #### Steps in Policy Evaluation 1. **Authentication:** Taloflow first authenticates the principal, typically a registered user authenticated by Auth0. The system can also work with anonymous users and temporary credentials. 2. **Policy Processing:** Taloflow processes the requested information to determine applicable policies and boundaries. The result is a list of possible policies based on the principals and resources. 3. **Evaluating Policies:** Taloflow evaluates all policies. The order of evaluation does not impact the result, but all boundary policies are evaluated first for efficiency. It is denied if there is no ALLOW at some level for the request. All deny policies are then evaluated. If any policy denies the request, it is denied. Finally, the system looks for an ALLOW policy that grants access and accumulates the scopes in the "allow" policies. 4. **Determining Request Outcome:** Taloflow processes the policies against the request context to determine whether to allow or deny the request. #### Processing the Request Context Taloflow gathers the following information into a request context: * **Actions (Operations):** The actions or operations the principal wants to perform. * **Resources:** The Taloflow resource object on which the actions are performed. * **Principal:** The user, role, federated user, or application sending the request, including associated policies. * **Environment Data:** Information attached to the request, such as IP address, user agent, SSL status, GraphQL request details, or time of day. * **Resource Data:** Data related to the requested resource, such as evaluation ID or workspace ID. ### Types of Policies Taloflow evaluates policies based on the types that apply to the request context: 1. **Identity-Based Policies:** Attached to users, groups, or roles and grant permissions. Taloflow checks these policies for at least one Allow and no Denies. 2. **Resource-Based Policies:** Grant permissions to the principal specified in the policy. Taloflow checks resource- and identity-based policies for at least one "allow" and no "denied." 3. **Permissions Boundaries:** Set the maximum permissions an identity-based policy can grant. Both identity-based policies and permissions boundaries must allow the action. 4. **Taloflow Organizations Control Policies (OCPs):** These policies specify the maximum permissions for an organization or organizational unit (OU). OCPs, identity-based policies, and resource-based policies must all allow the action. An explicit denial in any of these policies overrides the allow. ### Evaluating Policies #### Evaluating Identity-Based and Resource-Based Policies Identity-based and resource-based policies grant permissions to the identities or resources to which they are attached. When an entity requests access to a resource within the same account, Taloflow evaluates all permissions granted by both policy types. The resulting permissions are the total of both types. An explicit denial in either policy overrides the allow.
#### Evaluating Identity-Based Policies with Permissions Boundaries When evaluating identity-based policies and permissions boundaries for a user, the resulting permissions intersect with both categories. Adding a permissions boundary might reduce user actions while removing it might increase them. An explicit denial in either policy overrides the allow.
#### Evaluating Identity-Based Policies with Organizations SCPs When a user belongs to an account that is a member of an organization, the resulting permissions are the intersection of the user's policies and the SCP. Both the identity-based policy and the SCP must allow the action. An explicit denial in either policy overrides the allow.
### Determining Request Outcome Within an Account Taloflow evaluates all applicable policies to decide whether to allow or deny a request: * By default, all requests are implicitly denied, except for those made by the Taloflow account root user, who has full access. * An explicit allow in an identity-based or resource-based policy overrides this default. * A permissions boundary, organization's OCP, or session policy might override the allow with an implicit deny. * An explicit denial in any policy overrides any allows. ### Example of Permissions Allocated in the System The system has many permissions set up. Here are examples of a few. More permissions are added as the system evolves. #### Evaluation Permissions | Permission | Description | | -------------------- | ------------------------------- | | evaluation.view | View evaluations | | evaluation.create | Create evaluations | | evaluation.edit | Edit evaluations | | evaluation.delete | Delete evaluations | | evaluation.archive | Archive evaluations | | evaluation.unarchive | Unarchive evaluations | | evaluation.export | Export evaluations | | evaluation.rename | Rename evaluations | | evaluation.move | Move evaluations | | evaluation.invite | Invite users to evaluations | | evaluation.uninvite | Uninvite users from evaluations | #### Workspace Permissions | Permission | Description | | ---------------- | -------------------------- | | workspace.view | View workspaces | | workspace.create | Create workspaces | | workspace.edit | Edit workspaces | | workspace.delete | Delete workspaces | | workspace.rename | Rename workspaces | | workspace.move | Move workspaces | | workspace.invite | Invite users to workspaces | # Encryption Standards Encryption in transit and at rest across Taloflow services. ### Encryption Standards Communications between you and Taloflow servers are encrypted via industry best practices (HTTPS). Taloflow supports encryption of customer data at rest. #### Encryption in Transit All external traffic to and from Taloflow uses industry-standard HTTPS encryption: * **User connections** to Taloflow servers use HTTPS with modern SSL/TLS certificates * **API connections** from Vercel servers to Kubernetes clusters on Linode use HTTPS * **Database requests** use SSL encryption * **Behind-firewall requests**: Some internal requests within our firewall may not be encrypted, but these do not carry sensitive data and remain protected by firewall isolation * **Service mesh**: Full within-cluster encryption via service mesh is currently being deployed for additional defense-in-depth #### Encryption at Rest Customer data is encrypted when stored: * **Object storage**: Customer data in object storage is encrypted * **Database backups**: All backups are encrypted and compressed before storage * **Customer Personal Information (PII)**: Encrypted and managed by Auth0 * **Confidential information**: Decrypted only at the resolver level when needed for operations * **Block storage**: Linode-managed encrypted volumes * **Runtime secrets**: Delivered to workloads via Kubernetes Secrets. See [Secrets Management](/security/platform-controls/secrets-management). #### Cryptography governance Changes involving cryptography are peer-reviewed before deployment. # Logs, Audit Logs, and Backups Retention and contents of auth and audit logs, plus backup schedules. ### Scope This page covers **platform logs**, **audit logs**, and **backup schedules**. For retention of **evaluation data and exports**, see [Evaluation Data Retention](/security/platform-controls/evaluation-data-retention). #### Authentication Logs * **Auth0 sign-on and failure logs**: Retained for 6 days * **Extended analytics**: Authentication events are forwarded to Segment.io with 180-day retention * **Monitoring**: Threshold-based monitoring runs via scheduled cron jobs * **Analysis**: Currently, no active real-time analysis is performed on authentication logs #### Audit Logging Every API request generates an audit log entry containing: * **JTI** (JWT Token ID) * **User ID** * **Token thumbprint** * **Token expiration time** * **Request timestamp** * **Resolver-level access logs** for data access operations This zero-trust transaction recording ensures complete traceability of all platform actions. #### Data Backup Schedule **PostgreSQL Database**: * Hourly backups with minimum 3-day retention * Encrypted and compressed backups stored behind firewall * Nightly off-site backups for disaster recovery * State tracking with built-in attribution and archiving **Redis Database**: * Replicated database with persistent storage * Designed for continuous availability * Persistent storage on backed-up volumes * Stores current state (not historical data) **Object Storage**: * Used for evaluation configurations, generated exports, cached calculations, and static assets * Buckets are private and not publicly accessible * Access is key-based and scoped per service (least privilege) * Encryption keys are held by application services, not stored in object storage * Sensitive buckets use additional encryption controls * Most objects are regenerable from the database (backups focus on databases) **Block Storage**: * Linode-managed with replication * Periodic snapshots for application data * Database data handled through PostgreSQL/Redis mechanisms above # Tenant & Environment Isolation How Taloflow isolates tenants and separates dev, staging, and production. ### Scope This page covers tenant isolation and environment separation. ### Data ownership and storage Taloflow maintains clear separation between different types of data: **Taloflow Platform Data**: * Evaluation configurations * Methodology templates * Vendor databases * Rating criteria **Client Data**: * Evaluation results * Custom configurations * Reports and exports * All data created within your evaluations ### Personal Information (PII) * **No client personal data** is stored in Taloflow's database * **All Personally Identifiable Information (PII)** is managed exclusively by Auth0 * **Zero proprietary client data** storage outside of evaluation-specific information ### Environment Separation * **Development**: Isolated development environment * **Staging**: Pre-production testing environment * **Production**: Live customer environment Each environment is separated with no cross-contamination of data or credentials. No customer evaluation data is used in development or staging. Secrets and credentials are not shared across environments. ### Network segmentation Taloflow uses network segmentation to limit lateral movement. Subnets are restricted by firewall and security rules. Administrative access uses controlled entry points (for example, bastion-style access). ### Database Access Control * **Server-level restrictions**: Database access is controlled at the server level * **OPA authorization**: All user requests pass through Open Policy Agent evaluation * **Functional table access**: Some tables require related access for functionality (e.g., evaluations require access to policies, status, and settings tables) * **Resolver-level security**: Additional security controls at the application resolver level # Evaluation Data Retention How long evaluations are kept, who owns the data, and export options. ### Data availability and retention This page covers retention of **evaluation data and exports**. For **platform logs, audit logs, and backups**, see [Logs, Audit Logs, and Backups](/security/platform-controls/logs-audit-logs-and-backups). #### Evaluation Retention Period Completed evaluations remain available in Taloflow for **12 months** from the evaluation completion date. Use this window to: * Access and review evaluation results * Generate additional reports * Export data in various formats * Share findings with stakeholders After the 12-month period, availability is not guaranteed. Contact Taloflow before expiry if you need extended access. #### Data Ownership You retain ownership of your: * Evaluation results and analyses * Exported reports (PDF, Excel) * Custom configurations * Rating methodologies * Vendor assessments #### Export Capabilities You can export evaluation outputs at any time: * [Export to PDF](/data-export/export-to-pdf) * [Export to Excel](/data-export/export-to-excel) Exported files remain your property. Access to Taloflow does not affect your copies. #### Extended Retention If you need retention beyond 12 months, contact us to discuss options: * [Support Hub](broken://spaces/-MQkUmzRViVxDERN9vKk/pages/7w2btLpaU63hhnW4Dd7q) # Secrets Management How Taloflow stores and delivers runtime secrets (and why we avoid env vars). ### Scope This page covers how Taloflow handles application secrets in Kubernetes. It focuses on how secrets are stored, scoped, and mounted at runtime. ### Approach Taloflow delivers runtime secrets to workloads using **Kubernetes Secrets mounted as files**. We avoid injecting secrets via environment variables. ### Kubernetes Secret volume security layers When a secret is mounted as a volume, Kubernetes provides multiple layers of protection. 1. **tmpfs**: Secret volumes are memory-backed by default. They are not written to node disk. 2. **`readOnly: true`**: Pods can’t modify mounted secret files. 3. **`defaultMode: 0400`**: Secret files are readable only by the owner (typically `root`). 4. **Namespace isolation**: A Secret only exists in its namespace. Other namespaces can’t reference it. 5. **Encryption at rest (etcd)**: Kubernetes can encrypt Secrets at rest in etcd. 6. **No env var exposure**: Secret files are not present in the process environment table. {% hint style="info" %} Security is defense-in-depth. The mount settings reduce accidental leakage. RBAC still governs *who can read the Secret* via the API. {% endhint %} ### Why we avoid environment variables for secrets Environment variables are easy to leak. Common paths: * Included in debug output and crash dumps. * Visible in some process inspection workflows. * Accidentally echoed by startup scripts. Mounting secrets as files reduces these risks. ### Validation notes (for audits and questionnaires) If you’re validating Taloflow’s Kubernetes secret posture, typical checks include: * Secret volumes are mounted **read-only**. * Secret volume file mode is **restricted** (for example, `0400`). * Workloads cannot access secrets outside their **namespace**. * Secrets are **encrypted at rest** in the cluster backing store (etcd). # Security Operations Operational security practices for detection, response, and recovery. ### Scope Security operations covers the day-to-day practices that keep the platform safe and available. This page is the umbrella for: * [Malware Protection](/security/security-operations/malware-protection) * [Incident Response](/security/security-operations/incident-response) * [Disaster Recovery](/security/security-operations/disaster-recovery) * [Availability & Continuity](/security/security-operations/availability-and-continuity) * [Physical Security](/security/security-operations/physical-security) ### Key areas #### Monitoring and auditability Taloflow logs authentication and API activity for traceability. Retention and backup schedules are documented in [Logs, Audit Logs, and Backups](/security/platform-controls/logs-audit-logs-and-backups). #### Malware and supply-chain controls We use layered controls across repositories, developer environments, and CI/CD. Details are in [Malware Protection](/security/security-operations/malware-protection). #### Incident response We follow a defined incident response process for detection, containment, recovery, and communication. See [Incident Response](/security/security-operations/incident-response). #### Disaster recovery and business continuity We maintain backup and restore procedures and test recovery paths. See [Disaster Recovery](/security/security-operations/disaster-recovery) and [Availability & Continuity](/security/security-operations/availability-and-continuity). #### Physical security Physical security is handled by our infrastructure providers and their data center partners. See [Physical Security](/security/security-operations/physical-security). ### Security contact Send security questionnaires and document requests through the [Support Hub](broken://spaces/-MQkUmzRViVxDERN9vKk/pages/7w2btLpaU63hhnW4Dd7q). # Malware Protection Controls that reduce malware risk across code, devices, and deployment. ### Malware Protection Taloflow employs a three-layer malware protection approach: **1. Repository Level**: * All GitHub repositories undergo automated security scans * Continuous monitoring for known vulnerabilities in dependencies **2. Development Environment**: * ClamScan and RKHunter run via cron on all Linux development machines * Alternative security solutions for Windows and Mac developers as needed * Regular scans for file-level rootkits and malware signatures **3. Deployment Pipeline**: * Antivirus scans execute on Linux pods during pipeline runs before deployment * Code must pass security checks before reaching production This multi-layered approach ensures code security from development through production deployment. # Incident Response How Taloflow detects, contains, and communicates security incidents. ### Incident Response Plan Taloflow maintains a formal Incident Response Plan (IRP) to address security incidents effectively. #### Incident Commander The **Chief Technology Officer (CTO)** serves as the Incident Commander, with authority to make rapid decisions during security events. #### Five-Phase Response Process **1. Detection** * Identify and confirm the security incident * Initial impact assessment * Activate incident response team **2. Containment** * Isolate affected systems * Prevent further damage or data exposure * Implement kill switches if necessary **3. Eradication** * Remove the threat from the environment * Patch vulnerabilities * Verify complete removal **4. Recovery** * Restore systems to normal operation * Verify system integrity * Monitor for recurrence **5. Post-Incident Review** * Conduct forensic review * Document root cause analysis * Update procedures to prevent recurrence * Customer notification (if data breach affected customer information) #### Kill Switches Emergency response capabilities include: * **Network isolation**: Ability to disconnect affected systems * **Infrastructure lockdown**: Freeze deployments and access * **Data preservation**: Capture system state for forensic analysis #### Customer Notification In the event of a data breach that affects customer information, Taloflow will: * Notify affected customers promptly * Provide details about the nature of the breach * Outline steps taken to address the incident * Advise on any recommended customer actions # Disaster Recovery Recovery objectives, restore process, and emergency failover options. Taloflow maintains a proven disaster recovery capability that has been successfully tested in production environments. ### **Recovery Time Objective (RTO)** * **Full system recovery**: Approximately 6 hours to recreate Kubernetes clusters and recover database backups from scratch * **Typical data loss window**: Less than 1 hour in most scenarios * **Maximum potential data loss**: Up to 24 hours (worst-case scenario) {% hint style="success" %} **Proven Capability**: Our recovery procedures have been successfully executed in a real production outage, demonstrating the reliability of our backup and restoration processes. {% endhint %} ### **Redundancy Architecture** * Service clustering eliminates single points of failure within our infrastructure * Automated application and database restoration * Network redundancies across multiple systems **Emergency Failover Options**: In the event of a primary infrastructure provider outage: * **Off-site development installation**: Provides critical access capabilities during Linode/Akamai outages * **OVH Cloud emergency clusters**: Non-operational but available for rapid activation if needed * These alternatives enable continued operation during extended primary infrastructure failures **Infrastructure Dependencies**: * **Primary hosting**: Linode (Akamai) * **Edge services**: Cloudflare * **Extended recovery times** may occur if these primary providers experience regional or system-wide outages * Our multi-cloud failover strategy mitigates single-provider dependency risk # Physical Security Hosting provider facility security and where Taloflow data is located. Taloflow’s production infrastructure is hosted on **Akamai Connected Cloud (Linode)**. Physical security controls are primarily the responsibility of Akamai and its data center partners. ### Facility controls Data center physical controls are designed to prevent unauthorized access to systems and storage. Akamai (Linode) describes using layered facility controls, including: * Perimeter security (for example, fencing) * Multi-factor facility access (for example, swipe card + PIN) * Biometric checks (for example, face/eye scanners) and man-traps at some facilities * Trained security guards at some facilities * 24/7/365 monitoring * Visitor badging and access logging * Visitor escort requirements Taloflow personnel do not require routine physical access to data center facilities. Platform operations are performed through controlled, authenticated administrative access. Linode equipment is typically located in locked cages and cabinets. Access is restricted to authorized personnel with clearance. ### Compliance attestations Akamai publishes security and compliance information for its services. For the most current third-party attestations and certifications, reference Akamai’s Trust Center: * [Akamai Trust Center](https://www.akamai.com/trust-center) If you need specific documentation for a vendor review, contact Taloflow via the [Support Hub](broken://spaces/-MQkUmzRViVxDERN9vKk/pages/7w2btLpaU63hhnW4Dd7q). ### Data location Taloflow is deployed in specific Akamai Connected Cloud regions. If you have data residency requirements, contact Taloflow to confirm current region options. # Availability & Continuity Monitoring, redundancy, and continuity approach for the Taloflow platform. ### Scope This page covers how we monitor availability and how we maintain service continuity. For detailed recovery objectives and failover options, see [Disaster Recovery](/security/security-operations/disaster-recovery). For backup schedules and log retention, see [Logs, Audit Logs, and Backups](/security/platform-controls/logs-audit-logs-and-backups). ### Uptime and SLA Taloflow provides commercially reasonable efforts to maintain platform availability. We do not offer a specific uptime SLA in the standard agreement. For contractual terms, see the [Master Services Agreement](broken://spaces/-MQkUmzRViVxDERN9vKk/pages/5LECXwqL6dNCfhbUrGJG). ### Monitoring and incident communication Live uptime and incident updates are published on the [Status](broken://spaces/-MQkUmzRViVxDERN9vKk/pages/-MbItRgwaHx3aHJU8JPQ) page. If you’re seeing an outage or degradation, contact us via the [Support Hub](broken://spaces/-MQkUmzRViVxDERN9vKk/pages/7w2btLpaU63hhnW4Dd7q). ### Redundancy Taloflow uses service clustering and network redundancies to reduce single points of failure. Redundancy and continuity controls are complemented by backups and restore procedures. ### Continuity and recovery Taloflow manages infrastructure, backups, and disaster recovery procedures. Customers do not need to configure or maintain separate disaster recovery systems for Taloflow. For RTO / data loss guidance and emergency options, see [Disaster Recovery](/security/security-operations/disaster-recovery). ### Related pages * [Incident Response](/security/security-operations/incident-response) * [Security Overview](/security/security-overview) # Trust & Governance Compliance status, payments, and organizational security practices. Security posture, compliance status, and business controls. For technical controls, see [Platform Controls](/security/platform-controls). ### Pages in this section * [People & Security Culture](/security/trust-and-governance/security) * [Compliance & Certifications](/security/trust-and-governance/compliance-and-certifications) * [Payment Security](/security/trust-and-governance/payment-security) # People & Security Culture Hiring, training, and operating practices that support Taloflow security. ### Scope This page covers organizational and process controls. For technical controls (auth, encryption, logging, recovery), start at [Security Overview](/security/security-overview). ### Employee vetting * Background checks are performed for new hires, per local law. * New hires sign confidentiality and non-disclosure agreements. ### Security culture * Teams follow an internal security best-practices guide. * Employees and contractors complete security training and receive regular refreshers. * We run recurring checks to verify security practices are followed. ### Where to find technical controls This page stays intentionally non-technical. Use these pages as the source of truth for implementation details: * Identity and access: [Authentication & Access Control](/security/platform-controls/authentication-and-access-control) and [Authorization & Permissions](/security/platform-controls/authorization-and-permissions) * Encryption: [Encryption Standards](/security/platform-controls/encryption) * Logs and backups: [Logs, Audit Logs, and Backups](/security/platform-controls/logs-audit-logs-and-backups) * Malware controls: [Malware Protection](/security/security-operations/malware-protection) * Incident response and recovery: [Security Operations](/security/security-operations), [Incident Response](/security/security-operations/incident-response), and [Disaster Recovery](/security/security-operations/disaster-recovery) * Environment and tenant separation: [Tenant & Environment Isolation](/security/platform-controls/tenant-and-environment-isolation) * Billing and payments: [Payment Security](/security/trust-and-governance/payment-security) # Compliance & Certifications Current audit status, certifications, and materials for customer reviews. ### SOC 2 Type II Taloflow has retained **Prescient Assurance** to conduct a SOC 2 Type II audit. We will update this page when the report is available. If you need the latest status for a vendor review, contact us via the [Support Hub](broken://spaces/-MQkUmzRViVxDERN9vKk/pages/7w2btLpaU63hhnW4Dd7q). ### Industry Partnerships Taloflow is an **AWS Advanced Technology Partner**. This status requires a technical and architectural review. It also requires meeting AWS partner program requirements. ### What we share during compliance reviews We commonly provide the following, as applicable: * High-level security architecture and data flow details * A list of security controls relevant to customer due diligence * Confirmation of current audit and certification status Send requests through the [Support Hub](broken://spaces/-MQkUmzRViVxDERN9vKk/pages/7w2btLpaU63hhnW4Dd7q). # Payment Security How Taloflow processes payments and protects payment details. ### Scope This page covers payment processing and what Taloflow does (and does not) store. For application security controls, see [Security Overview](/security/security-overview). ### Payment processor Taloflow uses **Stripe** to process payments. Payment card details are handled by Stripe. Taloflow does not store raw card numbers. {% hint style="info" %} Taloflow receives Stripe identifiers and non-sensitive card metadata. Stripe stores and processes the underlying payment credentials. {% endhint %} ### Stripe security (high level) Stripe is designed to reduce the amount of sensitive payment data merchants handle. Stripe publishes security and compliance information in their documentation. See . ### What Taloflow stores Taloflow stores only the billing metadata needed to manage your account. This can include: * Stripe customer and subscription identifiers * Payment method identifiers (tokens) and non-sensitive card metadata (for example, brand and last 4 digits) * Invoice and transaction status ### Questions and customer requests If you need vendor documentation for a security review, send your request via the [Support Hub](broken://spaces/-MQkUmzRViVxDERN9vKk/pages/7w2btLpaU63hhnW4Dd7q). For Stripe’s own security and compliance information, see Stripe’s documentation. # Data Privacy Taloflow's architecture embeds data privacy at every layer, from initial design through implementation. This section documents Taloflow's privacy posture for data controllers, DPOs, and security reviewers. *** ## Core Privacy Principles Taloflow implements seven privacy principles that govern how personal data is handled across the platform. | # | Principle | Description | | - | --------------------------------- | ------------------------------------------------------------------------------------------------------- | | 1 | **Data minimization** | Only collect what is necessary. Credentials are never stored by Taloflow — delegated entirely to Auth0. | | 2 | **Deny-by-default authorization** | No user or service can access any resource unless an explicit policy grants access. | | 3 | **Encryption at every layer** | Application-level encryption before storage, TLS in transit, encrypted backups. | | 4 | **Pseudonymization** | UUIDs (`member_id`) are used as internal identifiers. PII mapping is limited to a single service. | | 5 | **Key sovereignty** | Taloflow controls all encryption keys. Keys are not delegated to the cloud provider. | | 6 | **Full lifecycle control** | Collection, processing, storage, access, retention, and deletion are all documented with controls. | | 7 | **Enforcement in code** | Privacy controls are implemented as middleware and shared libraries, not left to developer convention. | *** ## What Is in This Section | Topic | Page | | ------------------------------------ | ------------------------------- | | What personal data we collect | Personal Data Inventory | | GDPR rights and how to exercise them | Data Subject Rights | | What data we do not collect | Data Minimization Policy | | How data flows through the system | Data Flow Diagrams | | Third-party processors we use | Third-Party Subprocessors | | Our compliance maintenance schedule | Compliance Maintenance Calendar | {% hint style="info" %} For technical controls covering encryption, access management, and audit logging, see the **Security & Compliance** section. {% endhint %} # Data Subject Rights Taloflow supports all data subject rights under GDPR Articles 15–22. The table below summarizes each right, its technical implementation, and how to exercise it. ## Rights Summary | Right | GDPR Article | Implementation | How to Exercise | | ---------------------------------------------------- | ------------ | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | Right to Access | Art. 15 | Users can view and export their profile and evaluation data via the platform | Log in and use the export functionality; contact for a full data export | | Right to Rectification | Art. 16 | Users can update profile information directly in the platform | Update via account settings; changes propagate to Auth0 and the database | | Right to Erasure | Art. 17 | Account deletion triggers cascading removal across Auth0, database, cache, and S3 | Contact with a deletion request | | Right to Data Portability | Art. 20 | Evaluation data is exportable in machine-readable formats (PDF, Excel) | Use **Export to PDF** or **Export to Excel** in the platform | | Right to Restrict Processing | Art. 18 | Account suspension halts processing while retaining data | Contact | | Right to Object | Art. 21 | Users can opt out of non-essential processing (session/audit tracking) | Contact | | Right Not to Be Subject to Automated Decision-Making | Art. 22 | No automated decisions with legal effect are made about users | Not applicable — Taloflow is a decision-support tool; all decisions are human-made | ## Erasure: Technical Detail When an account deletion request is processed, the following steps are executed in order: 1. **Auth0 account deleted** — removes identity and authentication data 2. **Database cascade** — removes user references across `entity`, `group_detail`, `policy_history`, `tag_history`, `user_session`, and `audit_event` tables 3. **Cache invalidation** — Redis cache entries become unreadable after encryption key deletion (encryption-based erasure) 4. **S3 data removal** — evaluation documents associated solely with the deleted user are removed; shared evaluation data is anonymized (`member_id` references removed) 5. **Backup handling** — deleted data ages out of backup retention windows (maximum 1 year) {% hint style="info" %} Cache erasure is enforced cryptographically: because Redis entries are encrypted with a per-user key, deleting the key renders the cached data permanently unreadable without requiring explicit cache purges. {% endhint %} ## Data Retention | Data Type | Retention Period | Deletion Trigger | | ----------------------------- | -------------------------------------- | ---------------------------------------- | | User account data | Duration of account + 30 days | User deletion request or account closure | | Auth0 cached profiles (Redis) | TTL-based (configurable) | Cache expiry or key rotation | | Evaluation data | Duration of workspace membership | User request or workspace deletion | | Session logs | 90 days | Automated purge | | Audit events | 1 year | Automated purge | | Database backups | Daily: 30d / Weekly: 90d / Monthly: 1y | Automated rotation | | Application logs | 90 days online, 1 year archive | Automated rotation | {% hint style="warning" %} Data present in backups at the time of a deletion request will age out within the applicable backup retention window. Taloflow does not restore deleted data from backups absent a legal hold. {% endhint %} ## Contact For any data subject rights requests, email ****. Requests are acknowledged within 72 hours and fulfilled within the 30-day window required by GDPR Art. 12. # Personal Data Inventory Taloflow adheres to the principle of data minimization. The table below enumerates every personal data category we collect, the specific fields involved, the purpose of collection, the legal basis under GDPR, and where the data is stored. ## Data Inventory | Data Category | Specific Fields | Purpose | Legal Basis | Storage Location | | --------------- | -------------------------------------------------- | -------------------------------------------- | -------------------- | --------------------------------------------------- | | Identity | `email`, `first_name`, `last_name`, `full_name` | Account creation, login, user identification | Contract performance | Auth0 (primary), PostgreSQL (`member_id` reference) | | Authentication | `auth0_id`, hashed password | Secure login, session management | Contract performance | Auth0 (passwords never stored by Taloflow) | | Profile | Avatar URL, nickname | User experience personalization | Legitimate interest | Auth0, Redis (encrypted cache) | | Organization | Company name, legal name, `org_type` | Multi-tenant workspace management, billing | Contract performance | PostgreSQL (`group_header`, `other_setup` JSONB) | | Contact (Org) | Addresses, phone numbers | Billing, legal correspondence | Contract performance | PostgreSQL (within `other_setup` JSONB) | | Financial (Org) | `tax_ids`, `billing_code` | Invoicing, tax compliance | Legal obligation | PostgreSQL (org setup), Stripe (payment processing) | | Expert Profile | `expert_email`, title, bio, timezone, rate | Expert marketplace features | Consent | PostgreSQL (`expert` entity) | | Session / Audit | `member_id`, email, session timestamps, event type | Security monitoring, audit trail | Legitimate interest | PostgreSQL (`user_session`, `audit_event`) | | Activity | Evaluation opens/creates, dashboard loads | Product analytics, audit trail | Legitimate interest | PostgreSQL (`audit_event`) | ## Data We Do Not Collect Taloflow does not collect any of the following: * Biometric data * Health or medical data * Racial or ethnic origin * Political opinions or trade union membership * Geolocation tracking (beyond IP-derived timezone for expert profiles) * Social media activity * Browsing history outside the Taloflow platform * Payment card numbers (handled entirely by Stripe; never touch Taloflow servers) {% hint style="warning" %} Payment card data is submitted directly to Stripe via Stripe.js and is never transmitted to or stored on Taloflow infrastructure. {% endhint %} ## Internal Identifier Architecture All inter-service references use `member_id` (UUID), not email or name. The mapping between `member_id` and PII is held only in the organization-resolver service and Auth0. {% hint style="info" %} No other service holds the `member_id`-to-PII mapping. This limits PII exposure to a single, tightly controlled boundary, consistent with the pseudonymization principle. {% endhint %} # Third-party Subprocessors Taloflow uses a minimal number of third-party subprocessors. All are assessed for privacy compliance, and Data Processing Agreements (DPAs) are in place with each before any personal data is shared. ## Subprocessor List | Processor | Parent Company | Data Shared | Purpose | Compliance | DPA in Place | Location | | --------- | ------------------- | ------------------------------------------- | ----------------------------------- | ------------------------ | ------------ | -------- | | Auth0 | Okta, Inc. | Email, name, password hash | Identity management, authentication | SOC 2 Type II, ISO 27001 | Yes | USA | | Linode | Akamai Technologies | All data (infrastructure host) | Cloud infrastructure and hosting | SOC 2 Type II, ISO 27001 | Yes | USA | | Stripe | Stripe, Inc. | Subscription references only (no card data) | Payment processing | PCI DSS Level 1 | Yes | USA | ## What Taloflow Does Not Share * Payment card numbers are not shared with Taloflow or any processor other than Stripe. Card data is collected client-side via Stripe.js and never transits Taloflow infrastructure. * Evaluation content — product assessments, requirements, and scoring — is not shared with any third party. * Auth0 receives only the identity fields strictly necessary for authentication. It does not receive evaluation data, organizational content, or usage analytics. {% hint style="info" %} The use of Stripe.js means Taloflow operates outside PCI DSS scope for card data. No card numbers, CVCs, or expiry dates are ever present on Taloflow servers. {% endhint %} ## Subprocessor Detail ### Auth0 (Okta, Inc.) Taloflow delegates credential storage entirely to Auth0. Passwords never reach Taloflow servers in any form. In addition to credential storage, Auth0 provides: | Feature | Description | | --------------------------------- | --------------------------------------------------------------- | | Multi-factor authentication (MFA) | TOTP and push-based second factors | | Brute force protection | Automatic lockout after repeated failed logins | | Password breach detection | Integration with haveibeenpwned to flag compromised credentials | | Anomaly detection | Impossible travel and suspicious login detection | Auth0 is SOC 2 Type II and ISO 27001 certified. ### Linode (Akamai Technologies) All Taloflow infrastructure runs on Linode, now part of Akamai Connected Cloud. Physical data center security controls include: | Control | Detail | | ------------------ | ------------------------------------------------------ | | Perimeter security | Fencing and controlled entry points | | Access control | Multi-factor authentication and biometric verification | | Monitoring | 24/7 on-site monitoring | | Visitor management | Logged visitor access with escort requirements | Akamai is SOC 2 Type II and ISO 27001 certified. {% hint style="info" %} Taloflow retains full key sovereignty over data stored on Linode. Encryption keys are managed by Taloflow and are not accessible to Akamai. {% endhint %} ### Stripe (Stripe, Inc.) Payment card data is collected directly by Stripe.js in the user's browser and never touches Taloflow servers. Taloflow receives only: * A Stripe subscription ID * Plan status (via webhook) No card number, CVV, or expiry date is ever transmitted to or stored on Taloflow infrastructure. Stripe is PCI DSS Level 1 certified. ## Updates This page is updated when subprocessors are added or removed. Organizations requiring advance notice of subprocessor changes should review the DPA terms or contact . **Last reviewed:** April 2026 # Object Storage Assumptions These instructions will help you provide the key assumptions we need to perform an analysis of Object Storage costs for your use case. ## Number of Objects Please enter your best estimate for the number of objects stored. You can get this information from your cloud provider's console or via script. ### AWS Get the number of objects form the AWS S3 Lens console: 1. Access the [S3 Lens console](https://s3.console.aws.amazon.com/s3/lens). 2. Click on one of the available (there should be a default) S3 Lens dashboard in the table. 3. Once open, under **Overview**, you will see a total object count. 4. Convert the object count to an integer (e.g.: 850K :arrow\_right: 850,000) and enter into the number of objects field in the Taloflow form. {% hint style="warning" %} To access S3 Storage Lens dashboards, you must use an IAM user and not a root account. Your AWS administrator must update your IAM permissions to allow for the `s3:ListStorageLensConfigurations` {% endhint %} {% hint style="info" %} There are other ways to get the number of S3 objects covered in [this post](https://fuzzyblog.io/blog/aws/2019/10/24/three-ways-to-count-the-objects-in-an-aws-s3-bucket.html). {% endhint %} ### Google Cloud Platform Get the number of objects by running one of the scripts below in your terminal or in Google Cloud Shell: * `gsutil du | wc -l`will list every object (i.e.: file) in the default project * `gsutil du -p | wc -l` will list the objects for a specific project (replace `` with the relevant project ID. {% hint style="warning" %} If you have more than one project to include in the analysis, please run\ `gsutil du -p | wc -l`for each project and sum the results. {% endhint %} ### Microsoft Azure 1. Log into the [Azure Portal](https://portal.azure.com/) 2. Select **Storage Accounts** under the services list 3. Select a storage account 4. In the left panel, under the Monitoring group, click on **Metrics** 5. Set up the **Scope** to the storage account, **Metric Namespace** to `Blob`, and **Metric** to `Blob count` , and Aggregation to `Avg` (See #1 in the screenshot below). 6. The **Blob Count** (i.e.: object count) will be at a ticker at the bottom of the chart (See #2 in the screenshot below). 7. Convert the object count to an integer (e.g.: 850K :arrow\_right: 850,000) and enter into the number of objects field in the Taloflow form. ![](https://2292763076-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQkUmzRViVxDERN9vKk%2F-MaPM2JpLDHmYaFCxSGy%2F-MaPMTc60cA1Awy0PJ0W%2Fblobcount.png?alt=media\&token=099f896c-07ab-41a1-a52c-a117aceb97da) {% hint style="info" %} Blob count is equal to the number of blob objects in the storage account. {% endhint %} {% hint style="warning" %} Azure currently does not allow for multiple storage accounts in a single metric view, so you will need to repeat the steps above for each storage account and total the Blob counts. (Azure is working on this) {% endhint %} ## Data Transfer Estimates {% hint style="danger" %} Taloflow already captures the **INTER**-Regional GB Transfer IN and OUT from the uploaded cost reports. Do not include that data transfer when estimating the **INTRA**-Regional GB Transfer IN and OUT. {% endhint %} ### Intra-Regional GB Transfer IN (Monthly) {% hint style="warning" %} Entering data in this field is optional but may produce a more accurate analysis because the storage migration could result in some additional ongoing transfer costs between services on your cloud provider of origin and the new storage provider. {% endhint %} Please provide the GB monthly volume of data transfer that occurs when other services (like a virtual machine) read or write data to a storage bucket in the same region (i.e.: **intra**-region). This back and forth is not captured in your current usage reports because it is intra-regional and therefore it is free of charge. One way to estimate the amount of such traffic is to take your average file size in storage and multiply it by the number of times your services likely read or write data to object storage. ### Intra-Regional GB Transfer OUT (Monthly) Please provide your best estimate of the GB monthly volume of data transfer from storage containers or buckets into applications in the same region (a.k.a: intra-region/VPC traffic). Turning on VPC flow logging might help one get a more accurate estimate. * [VPC Flow Logs on AWS](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) * [Flow Logging on Microsoft Azure](https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-nsg-flow-logging-overview) * [Using VPC Flow Logs on Google Cloud Platform](https://cloud.google.com/vpc/docs/using-flow-logs) ## # Cloud Usage History For some reports, uploading usage history from cloud providers is required. This doc covers how to obtain that information from the major cloud providers, like AWS, Azure, and Google Cloud. ## Sharing cloud usage history Sharing cloud usage history helps us create an accurate representation of the cost-benefits of migrating to a new service (e.g.: AWS S3 :arrow\_right: Azure Blob Storage) or adopting a new product (e.g.: forecast APM cost). Once generated, you can download your usage history from a cloud provider and submit to Taloflow via our secure upload service. {% hint style="success" %} Cost and usage reports only contain billing-related information. {% endhint %} ## AWS Your AWS usage history is available in AWS Cost and Usage Reports (sometimes abbreviated as CURs). {% hint style="info" %} You must have[ AWS Billing and Cost Management Console Access](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/control-access-billing.html) to perform the following steps. {% endhint %} ### Generate AWS Cost and Usage Reports To start generating AWS Cost and Usage Reports, please follow these steps: 1. Sign in to the [AWS Billing and Cost Management console](https://console.aws.amazon.com/billing/home#/). 2. On the navigation pane, choose **Cost & Usage Reports**. 3. Click **Create Report**. Give your report a name. For example, `general-cost-report` . Make sure that both `Include resource IDs` and `Data refresh` settings are selected. 4. Under delivery options, select the S3 bucket where your reports currently reside and click **Verify** OR create a new S3 bucket if you do not currently have one for the report. If you get a prompt to add a default bucket policy, accept it. 5. We recommend you create a path prefix in the next field (e.g.: `main` ). Make sure that `Hourly`, `GZIP` and `Create New Report Version` are selected. Click **Next**, then click **Review & Complete**. {% hint style="info" %} AWS should generate your first Cost and Usage Reports in 8-24 hours time. {% endhint %} ### Download AWS Cost and Usage Reports 1. Sign in to the [AWS Billing and Cost Management console](https://console.aws.amazon.com/billing/home#/) 2. On the navigation pane, choose **Cost & Usage Reports**. 3. A list of your Cost and Usage Reports will be available. Click on the relevant one. 4. Click-through the S3 bucket folders until you select the latest report (ideally full month), and download to `csv.gz` file. {% hint style="warning" %} If it's available, it's much better to have a full-month report from the last month (not the current/ongoing month) so we can capture more variance. The report path will indicate the period like in this example: `20210501-20210601/` {% endhint %} ## Google Cloud Platform To export billing data from Google Cloud Platform (GCP) you have to create a billing report table in BigQuery. {% hint style="info" %} You must have [Billing enabled](https://cloud.google.com/billing/docs/how-to/modify-project#confirm_billing_is_enabled_on_a_project) on your project to perform the following steps. {% endhint %} ### Generate the Billing Report in BigQuery 1. Set up Cloud Billing data export to BigQuery by following [these instructions](https://cloud.google.com/billing/docs/how-to/export-data-bigquery-setup). 2. Run the following query in [BigQuery](https://console.cloud.google.com/bigquery) after replacing ``, ``, `` and `` with the name of the relevant project, the relevant BigQuery dataset you created in the previous step, the [Billing Account ID](https://console.cloud.google.com/billing), and the last month in the following format `yyyyMM` (e.g.: `202105`): {% hint style="info" %} This query will extract the relevant information for **Cloud Storage**. {% endhint %} ```sql SELECT billing_account_id, service.id AS service_id, service.description AS service_description, sku.id AS sku_id, sku.description AS sku_description, usage_start_time, usage_end_time, project.id AS project_id, location.location, location.country, location.region, location.zone, cost, currency, currency_conversion_rate, usage.amount AS usage, usage.unit, usage.amount_in_pricing_units AS usage_in_pricing_units, usage.pricing_unit, TO_JSON_STRING(credits) AS credits_array, IFNULL((SELECT SUM(CAST(c.amount * 1000000 as int64)) FROM UNNEST(credits) c), 0) / 1000000 AS total_credits, invoice.month, cost_type, adjustment_info.description AS adjustment_info_description, adjustment_info.mode AS adjustment_info_mode, adjustment_info.type AS adjustment_info_type FROM `..gcp_billing_export_v1_` WHERE service.description = "Cloud Storage" AND invoice.month = '' ORDER BY invoice.month, usage_start_time, usage_end_time; ``` ### Download the Billing Report from BigQuery 1. If there are *less than* 16k records from the query, then you can simply click **Save Results**, then select `CSV` (local file) to download the report. 2. If there are *more than* 16k records from the query, then you'll have to perform these additional steps: 1. Click on **Query History** 2. Click on the query you just ran 3. Click on the **Temporary Table** link (Destination Table) and click export to GCS 4. Chose `GZIP` compression 5. For file location, browse and select a GCS bucket where you want to save the file 6. For the file name it would be better to use a wildcard in case more than one file needs be created, so you can put something like `report-*.csv.gz` (Read more about this [here](https://cloud.google.com/bigquery/docs/exporting-data#exporting_data_into_one_or_more_files)) 7. When the export finishes you can download the files from your GCS bucket directly. {% hint style="warning" %} If there is more than 1 report file, you need to put all the files into a `.zip` or `.tar.gz` file before uploading to Taloflow. {% endhint %} ## Microsoft Azure {% hint style="danger" %} If you are on Microsoft Azure startup credits and can only access your billing data from the Microsoft Azure Sponsorships portal, **you cannot get an analysis performed by Taloflow**. This is because this limited report does not have critical data or report columns necessary for cost analysis, including: `bandwidth`, `chargeType`, `unitOfMeasure` and `productName`. {% endhint %} Microsoft Azure has many different account types and some of these have their own specific ways of accessing the billing report for export. The following two sets of linked instructions work in the vast majority of cases. However, if these steps are not relevant to your account type, please contact us at and we'll provide different instructions. 1. [Download from Cost Management + Billing console](https://docs.microsoft.com/en-us/azure/cost-management-billing/understand/download-azure-daily-usage#download-usage-for-pending-charges) 2. [Billing Export Method](https://docs.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-export-acm-data?tabs=azure-portal#create-a-daily-export) {% hint style="warning" %} If you're using the Billing Export method, please use **Actual Cost** and a **Daily export of last-month costs** (or month-to-date costs if last-month is unavailable). {% endhint %} # Browser and Platform Support ## Browser & Platform Support Taloflow supports the following web browsers: * Microsoft Edge (Chromium version) * Google Chrome * Other Chromium-based browsers * Opera * Safari * Brave For the best experience, we recommend using the latest version of your preferred browser.