Tables

Reusable grid views of your data that stay current with underlying sources—shape what you show, combine related information, and share a consistent view with your team.

Working with Tables and Views

Tables are saved, spreadsheet-style views of data from across your workspace. You decide what appears, how it is sorted and filtered, and how multiple sources fit together so everyone works from the same picture of the information.

Later sections cover configuration in detail—including sources, joins, calculated columns, and optional connections to external tools such as BI platforms when your CloudLink and warehouse setup support them.

Data sources you can build a table from:

• CloudLinks — Connect to external data warehouses (Snowflake, BigQuery, etc.)
• Apps — Data from your custom applications
• Elements — Shared data across teams and departments
• Tasks — Workflow steps and progress tracking

Create a table

1. In the left navigation, click Table.
2. Next to the Tables heading, click the More icon.
3. Click Create New Table.
4. Fill in the required fields:
   • Table name
   • Table handle
   • Category
   • Source
5. Click Create.

Explore the underlying data: Next to the Tables heading, click the More icon and select Explore Data. There you can see additional detail about what Elementum is reading from your databases for the table you are viewing.

Data View

Each table has a single Data view — the spreadsheet-style grid that displays the table’s data. Table admins manage what appears in this view through Configure in Table Settings, where they control columns, joins, filters, data cleansing, and calculated columns. Changes made in Configure are reflected in the Data view for all users.

Users can personalize how they see the Data view by applying their own filters and sort orders. These adjustments are per-user and do not change the underlying table configuration.

If different teams need different perspectives on the same table data — for example, finance focused on cost columns while logistics focuses on shipping fields — use Workspaces to create separate dashboard views rather than duplicating tables.

Workspaces

Workspaces within a table work the same way as Workspaces on the home page — they are dashboards that consolidate widgets and visualizations into a single place. When a Workspace is created inside a table, it is scoped to that table and shared with users who have access to it.

Workspaces are the way to create different “views” of a table’s data for different audiences. Each Workspace can contain its own set of widgets with distinct filters, sort orders, and chart configurations.

Create a table Workspace

1. In the table sidebar under Workspaces, click the More icon.
2. Select Create New Workspace.
3. Name the Workspace and click Create.
4. Add widgets by navigating to views or charts and selecting + Add To Workspace.

Shared Workspaces in a table are visible to other users who have access to that table, making them useful for team dashboards built around a specific dataset.

Why use Tables?

One current picture of the data. Tables read from connected sources, so when data changes in Elementum or your warehouse, what people see in the grid can reflect that without re-exporting files or merging attachments. That cuts down on copy-paste errors and on everyone working from slightly different versions of the same numbers.

Different questions, same foundation. You can define more than one table on the same sources: each table can use its own columns, filters, and joins to match how a team works. Sales might emphasize pipeline and revenue, support might emphasize open cases and response times, and finance might emphasize payment status—while still drawing from the same underlying data instead of maintaining parallel spreadsheets or extracts.

Configuring Data Sources

Snowflake View Configuration

When connecting to Snowflake or other data warehouses, you’ll configure:

Database Selection

• Choose your target database from available options
• Example: ACME_ANALYTICS_PROD

Schema Selection

• Select the appropriate schema within your database
• Example: DATA

View Name

• Define a meaningful name for your view
• Example: DET (Deal Execution Table)

Proper naming conventions help team members quickly identify and locate the right data views.

FAQ: Internal Snowflake Tables

Can users clean up Snowflake tables after deleting a table in Elementum?

If a table is deleted in Elementum and you still see related objects in the CloudLink schema, that is expected behavior for platform-managed storage.

The ELEMENTUM_PLATFORM schema is part of Elementum’s internal storage layer. It stores application state, intermediate processing data, and metadata required for platform operations.

Why are table names hashed (for example, K586D5CFC999253FA...)?

These tables are system-generated and support how Elementum manages platform objects, datasets, and execution state.

Hashed names are intentionally used to:

• Guarantee uniqueness across apps, workflows, and object types
• Prevent naming collisions in shared environments
• Support internal state management at scale

Is growth in table count expected over time?

Yes. As teams create objects, update configurations, and run processes, Elementum creates additional internal tables to support those operations.

Increases in internal table volume generally reflect normal platform usage, not a configuration issue.

Can we restrict or consolidate the number of internal tables?

No supported configuration is available to limit or consolidate these internal tables.

This storage model is required for platform isolation, scalability, and reliability. Restricting it can impact core functionality.

Are older internal tables safe to remove?

Internal tables should not be manually removed. Even when a table is not actively queried, it may still be needed for:

• Auditability and traceability
• Version rollback and recovery
• Dependency resolution across platform services

What if I delete a field or change a field type on a table linked to an Element?

If you delete a field or change its type on a table that is mapped to an Element field, the mapping can become invalid. When this happens, users may see errors in the list view or when loading the record detail page.

To resolve this issue:

1. Identify the mapped field causing the error.
2. Remove any dependencies on that field (for example, automations, formulas, filters, or views that reference it).
3. Delete the problematic mapped field.
4. Re-add the field from the unmapped table fields list so Elementum can create a fresh mapping.

After remapping, reapply any needed dependencies.

Table Features

Join types

Elementum provides four join types with visual representations so you can see how rows are combined. Each join type fits different reporting and analysis needs. For how relationships between records and objects are modeled more broadly, see Showing relationships.

Join configuration

• Source Field: Select the field from your primary table
• Joined Object Field: Select the matching field from the secondary table
• The system guides you through field selection with dropdown menus

Inner Join - Only Matching Records

What it does: Shows only records that exist in both tables with matching values.

Visual representation: Two overlapping circles, showing only the intersection.

Business use cases:

• Active customers with orders: Show only customers who have made purchases
• Employees with assigned projects: Display staff members who are actively working on projects
• Products with sales data: View only products that have been sold
• Vendors with active contracts: List suppliers who currently have agreements

Example scenario:

Customer Table: 1000 customers
Orders Table: 500 orders from 300 customers
Inner Join Result: 300 customers (only those who placed orders)

When to use: When you need to focus on records that have relationships and want to exclude unmatched data.

Left Outer Join - Keep All Left Records

What it does: Keeps all records from the left (primary) table, plus matching records from the right table.

Visual representation: Left circle completely filled, with matching portion from right circle.

Business use cases:

• All customers and their orders: Show every customer, including those who have not ordered
• Complete employee roster: Display all staff, whether they are on projects or not
• Full product catalog: Show all products, including those never sold
• Marketing campaign analysis: View all contacts, showing who responded to campaigns

Example scenario:

Customer Table: 1000 customers
Orders Table: 500 orders from 300 customers
Left Join Result: 1000 customers (700 show no orders, 300 show order data)

When to use: When your primary concern is the complete dataset from your main table, but you want to enrich it with available data from another source.

Right Outer Join - Keep All Right Records

What it does: Keeps all records from the right (secondary) table, plus matching records from the left table.

Visual representation: Right circle completely filled, with matching portion from left circle.

Business use cases:

• All orders with customer details: Show every order, even if customer data is missing
• Complete transaction log: Display all payments, including those without customer profiles
• Full support ticket history: Show all tickets, even if user accounts were deleted
• Inventory movements: Track all stock changes, including anonymous transactions

Example scenario:

Customer Table: 1000 customers
Orders Table: 500 orders (50 from deleted/unknown customers)
Right Join Result: 500 orders (450 with customer data, 50 without)

When to use: When you need complete data from your secondary table and want to see what primary table data is available to enrich it.

Full Outer Join - Keep Everything

What it does: Keeps all records from both tables, whether they match or not.

Visual representation: Both circles completely filled, showing all data from both sources.

Business use cases:

• Complete data audit: See all customers AND all orders, identifying gaps
• System migration: Compare old and new systems to ensure no data loss
• Reconciliation reports: Match financial records from different systems
• Master data management: Combine multiple data sources into one comprehensive view

Example scenario:

Customer Table: 1000 customers
Orders Table: 500 orders from 300 customers (50 from unknown customers)
Full Outer Join Result: 1200 records (700 customers with no orders, 300 customers with orders, 50 orders without customer data)

When to use: When you need to see the complete picture from both data sources and identify what data exists, what’s missing, and what’s orphaned.

Choosing the right join: Start by asking yourself: “Do I need ALL records from my primary table, or only the ones that have matching data?” This will help you decide between inner joins (matches only) and outer joins (keep everything).

Table Settings

The Table Settings section of the sidebar provides access to configuration, data quality, metadata, and access control for each table. The settings are organized into four areas: Configure, Data Cleansing, Table Details, and Roles & Permissions.

Configure

Configure is the management screen for the Data View. Open it from Table Settings → Configure in the table sidebar. This is where table admins control what data appears in the grid and how it is shaped.

The Configure screen has three areas:

Toolbar — Actions that apply to the table as a whole:

• Join — Combine data from other tables. See Join types for details.
• Filter — Apply filters that affect the Data view for all users. See Filtering, search, and data operations.
• Data Clean — Open Data Cleansing tools to standardize, deduplicate, and fix data quality issues.

Columns — Manage which columns appear in the Data view:

• Visible Columns — Columns currently shown in the grid. Drag to reorder, or click Hide All to move them all to Hidden.
• Hidden Columns — Columns available in the table but not shown in the grid. Click Show All to make them all visible.
• Search Columns — Find a specific column by name across both lists.
• + Calculated Column — Add a formula-based column. See Calculated columns.
• Each column card shows the field name and its source. Use the drag handle to reorder or the copy icon to duplicate.

Table Preview — A live preview of the Data view with your current configuration. Shows the row count and the data as it will appear to users. Click Full Screen to expand the preview.

When you are done making changes, click Save to apply the configuration to the Data view.

Data Cleansing

Data Cleansing helps you review and fix value mismatches that result from joins. When two tables are joined, some values in the join field may not match exactly — Data Cleansing surfaces those discrepancies so you can resolve them. Access it from Table Settings → Data Cleansing in the table sidebar, or from the Data Clean button in the Configure toolbar.

Data Cleansing requires at least one join on the table. If there are no joins configured, the screen displays “No current Joins on Table. Add one to use Data Cleansing.”

How it works:

1. Select Join — Choose which join to review from the dropdown on the right.
2. Review match results — The Table Join Match Percentage shows what percentage of values are Matched versus Unmatched across the joined tables.
3. Switch between tabs:
   • Unmapped — Values from the original table that did not find a match in the joined table. Each row shows the original value, a confidence score, the number of occurrences (count), and a suggested replacement value.
   • Mapped — Values that have already been matched, either automatically or manually.
4. Resolve mismatches — For unmapped values, review the suggested replacement and accept or override it. Select one or more rows and click Apply Selected Matches.

Intelligent Matching — Elementum can suggest matches automatically based on similarity. Click Apply Intelligent Matches to accept the suggestions, or click the gear icon to adjust the confidence percentage threshold for what qualifies as a match.

Run Data Cleansing after configuring joins and before setting up Data Mining triggers or AI Search on a table. Clean join mappings produce more accurate downstream results.

Table Details

Table Details shows the properties that were set when the table was first created. Access it from Table Settings → Table Details in the table sidebar.

General:

• Table Name — The display name for the table. Editable.
• Category — The category the table belongs to (for example, Customer Support). Editable via dropdown.
• Source — The data source the table reads from. This is set at creation and cannot be changed. The link opens the source object directly.

Cloud Details:

• Cloud — The cloud connection used by the table (for example, Default Elementum Connection). Read-only.

Roles & Permissions

Each table has its own Roles & Permissions settings that control who can view, edit, and administer the table. Access it from Table Settings → Roles & Permissions in the table sidebar. Table roles work the same way as app-level roles.

Managed roles — Predefined roles with fixed permissions. You manage membership only (users and groups) through Manage membership on each role card.

• Content Editor — View and edit content in the table.
• Content Viewer — View content in the table (read-only).
• Table Admin — Full admin access to the table, including configuration, data cleansing, and role management.

Custom roles — For more granular control, click Create custom role to define a role with specific permissions tailored to your needs. Custom roles give you full control over both permissions and membership.

For a full reference of permission types and how roles work across the platform, see Roles & Permissions.

Snowflake BI View Permissions

When using the Snowflake View feature, you need to configure permissions for two distinct purposes: allowing Elementum to create and manage the views, and allowing your users or BI tools to query the views. For Snowflake account and connection setup before BI views, see Connect Snowflake to Elementum.

Elementum Platform Permissions

The Snowflake user account configured in your CloudLink connection needs permissions to create and manage BI views in your desired database and schema.

Required for BI View Creation: These permissions must be granted to the Elementum role before you can create BI views. Without these permissions, the platform cannot create views in your specified Snowflake database and schema.

Grant these permissions to enable Elementum to manage BI views:

-- Replace placeholders with your actual values:
-- <DB_NAME> - Database where BI views will be created
-- <SCHEMA_NAME> - Schema within the database for BI views
-- <ELEMENTUM_USER_ROLE_NAME> - Role assigned to the Elementum user (typically "ELEMENTUM")

USE ROLE ACCOUNTADMIN;

-- Grant USAGE on the database
GRANT USAGE ON DATABASE <DB_NAME> TO ROLE <ELEMENTUM_USER_ROLE_NAME>;

-- Grant USAGE on the schema
GRANT USAGE ON SCHEMA <DB_NAME>.<SCHEMA_NAME> TO ROLE <ELEMENTUM_USER_ROLE_NAME>;

-- Grant the ability to manage views in the schema
GRANT CREATE VIEW ON SCHEMA <DB_NAME>.<SCHEMA_NAME> TO ROLE <ELEMENTUM_USER_ROLE_NAME>;

Critical: Do Not Change View Ownership: Once Elementum creates a BI view, the ownership must remain with the ELEMENTUM role. Changing ownership to another role will break Elementum’s ability to manage, update, or delete the view. If view ownership is accidentally changed, you must transfer it back to the ELEMENTUM role using GRANT OWNERSHIP ON VIEW <DB_NAME>.<SCHEMA_NAME>.<VIEW_NAME> TO ROLE <ELEMENTUM_USER_ROLE_NAME>;

Example:

-- Example using common values
USE ROLE ACCOUNTADMIN;

GRANT USAGE ON DATABASE ANALYTICS_DB TO ROLE ELEMENTUM;
GRANT USAGE ON SCHEMA ANALYTICS_DB.BI_VIEWS TO ROLE ELEMENTUM;
GRANT CREATE VIEW ON SCHEMA ANALYTICS_DB.BI_VIEWS TO ROLE ELEMENTUM;

Best Practice: Create a dedicated schema for your BI views (e.g., BI_VIEWS or ELEMENTUM_BI) to keep them organized and separate from other data structures.

End User Query Permissions

After Elementum creates a BI view, you need to grant permissions to the Snowflake roles used by your BI tools, analysts, or other users who need to query the views.

Grant these permissions to enable users to query BI views:

-- Replace placeholders with your actual values:
-- <DB_NAME> - Database used in the creation of the BI view
-- <SCHEMA_NAME> - Schema used in the creation of the BI view
-- <VIEW_NAME> - Name used in the creation of the BI view
-- <ROLE_NAME> - Role assigned to users that need access to query the BI view

USE ROLE ACCOUNTADMIN;

-- Grant USAGE on the database
GRANT USAGE ON DATABASE <DB_NAME> TO ROLE <ROLE_NAME>;

-- Grant USAGE on the schema
GRANT USAGE ON SCHEMA <DB_NAME>.<SCHEMA_NAME> TO ROLE <ROLE_NAME>;

-- Grant SELECT on the specific view
GRANT SELECT ON VIEW <DB_NAME>.<SCHEMA_NAME>.<VIEW_NAME> TO ROLE <ROLE_NAME>;

Example for a specific view:

-- Example granting PowerBI role access to a sales dashboard view
USE ROLE ACCOUNTADMIN;

GRANT USAGE ON DATABASE ANALYTICS_DB TO ROLE POWERBI_USERS;
GRANT USAGE ON SCHEMA ANALYTICS_DB.BI_VIEWS TO ROLE POWERBI_USERS;
GRANT SELECT ON VIEW ANALYTICS_DB.BI_VIEWS.SALES_DASHBOARD TO ROLE POWERBI_USERS;

Granting Access to All Future Views

If you prefer to grant permissions on all future views in a schema (so you don’t need to grant permissions for each new view individually), use this approach:

-- Replace placeholders with your actual values:
-- <DB_NAME> - Database used for BI views
-- <SCHEMA_NAME> - Schema used for BI views
-- <ROLE_NAME> - Role assigned to users that need access

USE ROLE ACCOUNTADMIN;

-- Grant USAGE on database and schema
GRANT USAGE ON DATABASE <DB_NAME> TO ROLE <ROLE_NAME>;
GRANT USAGE ON SCHEMA <DB_NAME>.<SCHEMA_NAME> TO ROLE <ROLE_NAME>;

-- Grant SELECT on all future views in the schema
GRANT SELECT ON FUTURE VIEWS IN SCHEMA <DB_NAME>.<SCHEMA_NAME> TO ROLE <ROLE_NAME>;

Example:

-- Automatically grant access to all future BI views for the analytics team
USE ROLE ACCOUNTADMIN;

GRANT USAGE ON DATABASE ANALYTICS_DB TO ROLE ANALYTICS_TEAM;
GRANT USAGE ON SCHEMA ANALYTICS_DB.BI_VIEWS TO ROLE ANALYTICS_TEAM;
GRANT SELECT ON FUTURE VIEWS IN SCHEMA ANALYTICS_DB.BI_VIEWS TO ROLE ANALYTICS_TEAM;

Recommended Approach: Using FUTURE VIEWS grants streamlines access management. When Elementum creates new BI views, users with this grant automatically have access without requiring additional permission changes.

Permission Setup Workflow

When setting up BI views:

1. Grant the Elementum role permissions to create and manage views in your target database and schema.
2. Configure your Elementum table and enable the Snowflake View feature through the Business Intelligence section.
3. Grant SELECT permissions to the roles used by your BI tools, analysts, or other users who need to query the view.
4. Configure your BI tools (PowerBI, Tableau, Looker) to connect to the Snowflake view using the appropriate role.

Common Issue: If users report “Object does not exist or not authorized” errors when querying BI views, verify that:

1. The view was successfully created by Elementum (check in Snowflake)
2. The user’s role has USAGE grants on both the database and schema
3. The user’s role has SELECT grant on the specific view or FUTURE VIEWS

Remember that grants must be applied at all three levels: database, schema, and view.

Calculated columns

Understanding calculated columns

Calculated columns let you add new columns derived from existing table data using Excel-like formulas.

What you can do

• Mathematical operations: Revenue = Quantity × Price
• Date calculations: Days_Open = TODAY() - Created_Date
• Conditional logic: Risk_Level = IF(Amount > 10000, "High", "Low")
• Text manipulation: Full_Name = CONCAT(First_Name, " ", Last_Name)
• Aggregations: Total_Orders = COUNT(Orders.ID)

Column configuration

• Column name: Give your calculated column a descriptive name
• Function: Enter your formula using Excel-like syntax
• Format options:
  • Format as percentage
  • Format as percentage and multiply by 100
  • Format as currency
  • No formatting (default)

Available functions

Elementum supports calculation functions similar to Excel, including:

• Mathematical: SUM, AVERAGE, MIN, MAX, ROUND, POWER, SQRT
• Logical: IF, AND, OR, NOT
• Date/Time: DATE, NOW, DATEDIF, WEEKDAY, YEAR, MONTH, DAY
• Text: CONCAT, LEFT, RIGHT, MID, UPPER, LOWER, TRIM
• Lookup: VLOOKUP, COUNTIF, SUMIF, SEARCH, FIND

For a complete list of functions and their syntax, see the Calculations Reference.

Example formulas

Sales analytics

Commission = IF(Deal_Value > 50000, Deal_Value * 0.05, Deal_Value * 0.03)
Days_in_Pipeline = DATEDIF(Created_Date, NOW(), "D")
Deal_Size_Category = IF(Deal_Value > 100000, "Enterprise", IF(Deal_Value > 10000, "Mid-Market", "SMB"))

Customer analysis

Customer_Lifetime_Value = SUM(Orders.Total_Amount)
Last_Order_Days = DATEDIF(MAX(Orders.Order_Date), NOW(), "D")
Customer_Status = IF(Last_Order_Days > 365, "Inactive", "Active")

Financial reporting

Profit_Margin = (Revenue - Cost) / Revenue * 100
Quarterly_Growth = (Current_Quarter - Previous_Quarter) / Previous_Quarter * 100
Budget_Variance = Actual_Amount - Budget_Amount

Performance Consideration: While calculated columns are flexible, creating too many complex calculations can impact table performance. Each calculated column requires processing time when the table loads. For optimal performance:

• Limit complex calculated columns to essential business logic
• Use simple calculations when possible
• Consider pre-calculating values in your data source for frequently used complex formulas
• Monitor table load times and optimize as needed
• Increase warehouse size for better performance with complex calculations and large datasets

Excel-like syntax: If you use Excel formulas, Elementum calculation syntax follows similar patterns, so you can reuse familiar function names and structures.

AI Search

Table admins can enable AI Search on a Table. Setup follows the same process as for AI Search on Elements. For field to search, embedding service, attribute fields, and filters, see AI Search.

Filtering, search, and data operations

Filtering and search

Filter options

• Field selection: Choose any column for filtering
• Operators: Contains, equals, greater than, less than, etc.
• Values: Direct input or dropdown selection for known values
• Condition groups: Combine multiple filters with AND/OR logic

Filter management

• Add condition: Build complex filter logic
• Condition groups: Organize related filters
• Clear all: Reset filters quickly
• Save filters: Store frequently used filter combinations for quick access

Data operations

Joins and data quality

Table admins manage joins and data cleansing through the Configure screen. See Join types and Data Cleansing for details.

Real Business Examples

Sales Pipeline View

Combine Opportunities, Accounts, and Contacts tables. Join Opportunity.AccountID to Account.ID, then add a calculated column for Potential Revenue (Amount × Probability). Filter to Stage = “Proposal” and Region = “West” to surface active opportunities with contact details and revenue potential.

Customer 360 View

Combine Customers, Support Tickets, and Orders tables. Join on Customer.ID to both Tickets.CustomerID and Orders.CustomerID, then add a calculated column for Lifetime Value using SUM(Order.Total). Filter to contacts within the last 90 days for a complete customer history with support and purchase context.

Operations Dashboard

Combine Inventory, Orders, and Shipping tables. Join Orders.ProductID to Inventory.ProductID, then add a calculated column for Stock Level (Inventory.Quantity − Orders.Pending). Filter to rows where Stock Level falls below the reorder point for real-time inventory status with reorder alerts.

Best Practices

Performance optimization

Join strategy

• Start with your primary data source
• Join only necessary tables
• Use indexed fields for joins when possible
• Limit joins to 3-4 tables for optimal performance
• Increase warehouse size for better performance with complex multi-table joins

Each join multiplies data processing requirements. More than 4 joins can significantly slow down your views. Consider creating pre-joined summary tables for complex views you use frequently.

Query optimization

• Apply filters before joins when possible
• Only display columns you need
• Use calculated columns sparingly
• Archive old data regularly
• Increase warehouse size for better performance with large datasets and complex operations

Data governance

Naming conventions

• Use clear, descriptive table names
• Include data source and purpose
• Example: Sales_Pipeline_Q4_2024

Access control

• Configure appropriate permissions (Roles and permissions)
• Document table purposes and owners
• Regular access reviews

Data quality

• Validate join results
• Monitor for data inconsistencies
• Set up alerts for missing data

Layout, clarity, and performance monitoring

View design

• Keep views focused and simple
• Group related columns together
• Use meaningful column headers
• Provide context through descriptions

Performance monitoring

• Track query execution times
• Monitor user engagement
• Optimize frequently used views

Related documentation

• Core concepts — How Apps, Elements, Tables, and Tasks work together
• Data best practices — Choosing structures and organizing shared data
• Setup CloudLink — Connecting warehouses and CloudLink-backed sources
• Connect Snowflake to Elementum — Snowflake roles, networking, and BI view prerequisites
• Showing relationships — Relationships between records and join-style modeling
• Calculations — Formula syntax and functions for calculated columns
• Data mining — Triggers and patterns that use table data
• Analytics — Charts and dashboards in the product
• Reports — Excel and PDF report templates
• AI Search — Enabling search on Tables and Elements

Tables and views surface business data in one place: current figures, consistent definitions, and controls that help you keep reports accurate as sources change.