> AI agents: this is one page from Mammoth Analytics documentation. The index of all pages as Markdown is https://docs.mammoth.io/llms.txt. Append `.md` to any docs URL, or send `Accept: text/markdown`, to get Markdown.

# Enterprise architecture patterns

> Organize workspaces, projects and roles in large Mammoth deployments, standardize pipelines, share certified Views across teams, and use a governance checklist.

At enterprise scale, the technical challenges of Mammoth become organizational: how does the marketing team share clean data with finance without giving them access to raw CRM records? How does a central data team govern a workspace used by 12 departments? This guide is for enterprise architects and administrators. It covers workspace organization, role design, pipeline standards, cross-team sharing, cataloging, and a governance checklist.

## Workspace organization

### Single workspace versus multiple workspaces

**Single workspace**: all teams in one Mammoth workspace:

- Simpler administration, one billing account
- All data is in one place, which makes cross-team joins easier
- Requires careful RBAC to prevent accidental data access
- Best for: companies with a single data governance model

**Multiple workspaces**: separate workspaces per department or environment:

- Hard data isolation between departments
- Each workspace has its own billing, user management, and admin
- Cross-workspace data sharing via exported files or shared warehouse tables
- Best for: enterprises with distinct data governance requirements per business unit, or separate legal entities

**Recommendation for most enterprises:** single workspace with well-designed RBAC. Multiple workspaces add administrative overhead and makes cross-team analytics harder. Move to multiple workspaces only when regulatory or organizational requirements mandate it.

### Folder structure

Organize the Data Library with a consistent folder hierarchy:

```plaintext
Data Library/
├── Raw/                    # Unmodified source data
│   ├── CRM/
│   ├── Finance/
│   └── Operations/
├── Staging/                # Intermediate pipeline outputs
│   ├── CRM/
│   └── Finance/
├── Shared/                 # Certified, cross-team Views
│   ├── customer_master/
│   ├── product_catalog/
│   └── date_dimension/
└── Department/             # Department-specific datasets
    ├── Marketing/
    ├── Sales/
    └── Finance/
```

The `Shared/` folder contains the certified datasets that multiple teams consume. Data engineers own these; analysts reference them via **Lookup**.

Folders in the Data Library are an organizational convention, not an access-control boundary. Mammoth does not support per-folder permissions. The layout above only works if it's paired with the project-level RBAC described next.

## Role design at scale

Mammoth's permission model is layered, not a single flat role list:

- **Workspace roles:** Owner and Member—control who can administer the workspace (users, billing, API keys) and who can create projects
- **Project roles:** Project Admin and Project Editor—control what a user can do with data inside a given project (Data Library, pipelines, Views). This is the level enterprise governance mostly operates at, since access is granted per project, not per folder
- **Dashboard roles:** Dashboard Editor and Dashboard Viewer—control who can edit a dashboard and who can only view it

### Recommended role mapping

| Organizational role | Mammoth role | Scope |
| --- | --- | --- |
| Data engineer | Project Admin | Full project: can edit pipelines and manage the Data Library |
| Analytics engineer | Project Editor | Build and edit Views/pipelines; no project administration |
| Department analyst | Project Editor (own project) | Full data access in their team's project; add them only to projects they need |
| Business user | Dashboard Viewer | Read-only access to dashboards |
| External stakeholder | Dashboard Viewer (shared link) | Specific published dashboard only |
| Workspace administrator | Workspace Owner | User management, billing, workspace-wide settings |

Because Mammoth has no per-folder permissions, teams that need hard data isolation (not just an organizational convention) should use **separate projects**, not separate folders within one project. The project is the real permission boundary.

### Access control for sensitive data

For datasets containing PII, financial data, or regulated content:

1. Keep these datasets in a project scoped to the people who need them (a restricted `CRM/PII` folder is a naming convention for humans, not an access barrier)
2. Create a de-identified View in a separate shared project, and give other teams access to what is built from it (for example, dashboards shared as Dashboard Viewer)
3. Document the de-identification approach in the View description

### Shared View pattern

The most important governance pattern: analysts never access raw data directly. Instead, the data engineering team:

1. Ingests and cleans raw data (as Project Admin/Editor on the raw/staging project)
2. Creates a certified View in a shared project (e.g., `customer_master_v2`)
3. Shares dashboards built on that View with other teams as Dashboard Viewer, or exports the View to them
4. Analysts build their analyses from the Shared View's outputs

When the underlying data structure changes, only the pipeline between raw and the Shared View needs updating—all downstream analyst work is insulated.

## Pipeline standardization

At scale, inconsistency in pipeline design becomes a maintenance burden. Standardize across teams:

### Naming conventions

Establish naming conventions for all pipeline artifacts:

| Artifact | Convention | Example |
| --- | --- | --- |
| Raw datasets | `raw_{source}_{object}` | `raw_sf_opportunities` |
| Staging datasets | `stg_{source}_{object}` | `stg_sf_opportunities` |
| Shared Views | `{domain}_{entity}_{version}` | `crm_customers_v3` |
| Automations | `{team}_{cadence}_{purpose}` | `finance_daily_gl_consolidation` |

### Pipeline documentation standard

Every pipeline task description should answer: **what does this task do, and why?**

Bad: `"Filter task"`\
Good: `"Filter to active customers only (Status = 'Active'). Excludes churned accounts per revenue recognition policy. Last reviewed 2026-01-15."`

This matters for audit, onboarding new team members, and debugging failures 6 months after build.

### Transformation layer separation

Separate pipelines into three layers:

- **Raw layer:** exact copy of source data, no transformations
- **Staging layer:** type casting, basic normalization, and column renaming, one-to-one with source tables
- **Shared layer:** business logic, joins, aggregations, certified for consumption

Each layer is a separate pipeline. This separation makes it possible to change source extraction without breaking business logic, and vice versa.

![Three layers: raw datasets, staging datasets (type casts, renames), then certified shared Views such as crm_customers_v3.](https://docs.mammoth.io/api/v1/images/20260805_052518_enterprise-patterns-three-layer-architecture1.jpg)

## Cross-team data sharing

### Shared Views as contracts

A Shared View is a contract between the data engineering team and consumers. Treat it like an API:

- Version the View name when the schema changes: `customer_master_v2` → `customer_master_v3`
- Maintain the previous version while consumers migrate
- Announce deprecation with a timeline in the View description
- Never change a Shared View schema silently

### Reference datasets

Some datasets are consumed by many pipelines: product catalogs, date dimensions, exchange rate tables, geography hierarchies. Maintain these in `Shared/Reference/` and treat them as first-class assets:

- Data engineering owns them
- Changes go through a review process
- Version history is maintained
- All pipelines that consume them document which version they reference

### Publishing Views for external access

For data that needs to go outside the workspace:

1. **Download** (CSV/Excel) or a **Live Link** for spreadsheet consumers
2. **Export** → **Databases** (BigQuery, PostgreSQL, SQL Server, Redshift) for warehouse consumers, kept current by Auto-sync on each pipeline run
3. **Publish** → shareable link for business users who need visualization without Mammoth access
4. An **SFTP** export task attached to the pipeline for legacy systems that consume files

## Data catalog and lineage

### Documenting the data estate

For enterprise deployments, the Data Library's metadata fields serve as a lightweight data catalog:

- **Dataset description:** what this data is, where it comes from, who owns it
- **Pipeline task descriptions:** what each transformation does and why
- **View description:** what the View represents, who the intended consumers are, what business questions it answers

Maintain a master catalog document (Google Doc or Notion) that lists all Shared Views with:

- Name and version
- Owner
- Business domain
- Upstream sources
- Downstream consumers
- Refresh schedule
- Last reviewed date

### Lineage visibility

The pipeline visualization in Mammoth shows the transformation chain for any dataset. For audit and debugging, this answers: "where did this number come from?"

For complex lineage that crosses multiple pipelines and datasets, document the full lineage in the master catalog document. Mammoth's visual lineage covers within-pipeline lineage but not cross-pipeline dependencies.

## Governance checklist for enterprise deployments

**Access and security:**

- [ ] Project/workspace roles defined and mapped to organizational roles
- [ ] PII and sensitive data isolated in a restricted project (not just a labeled folder)
- [ ] All access reviewed quarterly
- [ ] Activity Log exported periodically for audit records (export requires an Enterprise plan)

**Pipeline standards:**

- [ ] Naming conventions documented and enforced
- [ ] All Shared Views have descriptions and owners
- [ ] Transformation layer separation implemented
- [ ] All pipeline tasks have descriptions (not just names)

**Operations:**

- [ ] Critical automations have failure notifications configured (Messaging automation, or a Checkpoint Alert task in the pipeline)
- [ ] Row count and data quality checks (Data Check task) in all critical pipelines
- [ ] Automation status (last run success/failure) reviewed regularly by data engineering team
- [ ] Data freshness SLAs documented for each Shared View

**Change management:**

- [ ] Shared View versioning process documented
- [ ] Change notification process for Shared View consumers
- [ ] Rollback procedure documented for each critical pipeline

---
Source: https://docs.mammoth.io/guides/advanced/enterprise-patterns.md · Updated: 2026-10-13