TEST JD
|
You may click on the Accessibility button to enlarge the fonts. Permission granted for use by the visually impaired audience only on listen.wels.net.
|
Updated 6/2/2026 at 1:15pm
Worksheet added at 1:51pm
Acquia DAM Governance & Implementation Framework
Unified board-ready document integrating governance, operating standards, and implementation guidance for WELS digital asset management and HubSpot delivery.
1. Executive Summary
- This document consolidates the Acquia DAM configuration discussion into a single governance and implementation framework. It is intended to support leadership review, approval of enterprise standards, and coordinate execution across departments.
- The framework establishes Acquia DAM as the controlled source for digital asset intake, management, and approved release, while HubSpot functions as the downstream delivery layer for web and public-facing experiences.
- The document also clarifies authority, metadata control, lifecycle management, external contributor handling, and cross-system rules so that operational configuration decisions are anchored to lasting governance standards.
Governance is structured as a joint communication and technology approach:
- Web Services: system configuration, integrations, and technical governance
- Communication Services: brand, editorial, and audience-facing governance
- Digital Services Exec Team (DSET): final authority for enterprise-impacting decisions
Leadership Decisions Supported by This Document
- Approve a centralized governance model for metadata, naming, security structure, and public delivery standards.
- Confirm department participation through designated coordinators operating within enterprise standards.
- Adopt SKU-based asset identification for product-oriented content to improve long-term manageability across DAM and HubSpot.
- Endorse lifecycle, compliance, and exception-management rules needed to keep the DAM sustainable as usage expands.
2. Purpose and Scope
Policy
Acquia DAM shall be governed as an enterprise platform serving multiple departments, websites, asset types, external contributors, volunteers, and public consumers. Governance applies to security, metadata, taxonomy, naming, workflows, integrations, and publication methods.
Implementation
This framework covers the operating model reflected in the original discussion document: approximately 20 departments, 35 websites, hundreds of products, internal and external contributors, no-login public consumption, and HubSpot synchronization for downstream delivery.
3. Governance Model
Policy
System permissions do not replace governance authority. Governance authority is distributed based on domain expertise:
- Technical structure and system integrity remain under Web Services
- Brand, editorial, and audience experience decisions remain under Communication Services
- Enterprise-impacting decisions require DSET oversight
Implementation
- Web Services governs metadata structure, naming system format, SKU structure, synchronization rules, and system integrity
- Communication Services governs content presentation, category experience, editorial standards, and public delivery experience
- DSET provides final approval on cross-system and enterprise-impacting decisions
- Departments operate within defined guardrails through designated coordinators
Decision Authority Matrix
| Decision Area | Decision Owner | Primary Contributors | Operating Note |
| Metadata field structure & dependencies | Web Services | DSET (as needed) | System-level governance |
| Metadata vocabulary & labels | Digital Communications Coordinator / Copy Editor | Web Services | Controlled vocabulary ownership |
| Naming conventions (file structure) | Web Services | None | Technical standard |
| Naming conventions (titles/descriptors) | Copy Editor | Digital Communications Coordinator | Editorial consistency |
| SKU structure | Web Services | DSET | Enterprise identifier model |
| Category tree & portal UX | Digital Communications Coordinator | Brand Manager, Web Services | Audience-facing structure |
| Public delivery standards | Communication Services Director | Web Services | Brand + experience consistency |
| Asset approval (content) | Digital Communications Coordinator | Brand Manager, Copy Editor | Public-facing approval authority |
| HubSpot synchronization | Web Services | Developers | System integration |
| Exception approval (enterprise impact) | DSET | Web Services, Comm Services | Final decision authority |
4. Security and Asset Group Framework
Policy
Asset groups are the primary security boundary within the DAM. Security shall be designed to protect internal assets, isolate external intake, and enable enterprise-wide access only where appropriate.
Implementation
- Global Brand Assets Group: enterprise logos, fonts, corporate templates, and general marketing photography available to all internal departments.
- Departmental Private Groups: one isolated group per department to prevent cross-department visibility unless specifically governed otherwise.
- Inbound Sandbox Groups: isolated intake zones for vendor and volunteer submissions pending coordinator review and release.
- Shared or cross-department asset groups may be established by Web Services when asset ownership or usage spans multiple ministries or teams.
Governance Rule
Cross-department assets shall not be duplicated into multiple groups as a substitute for governance. Shared access and shared ownership must be handled through intentional group design and a single governed source asset.
5. User Roles and Permissions
Policy
Roles shall be standardized globally rather than redefined by departments. Role design must support security, operational consistency, and scalable onboarding.
Implementation
- Acquia Admin: full system configuration authority, including asset groups, metadata fields, and portal generation.
- Department Coordinator: manages uploads, metadata, and approval actions within the assigned departmental and matching inbound groups.
- Vendor: restricted uploader access limited to designated inbound locations and without category-tree visibility.
- Volunteer: no-login submission through a controlled submit portal.
- Public Consumer: no-login access only through approved public delivery methods such as HubSpot embeds or portals.
Governance Rule
No role may be expanded locally in a way that bypasses enterprise standards. Departments administer content; they do not redefine permission philosophy, metadata standards, or publication rules.
6. Metadata Governance
Policy
Metadata operates under a controlled vocabulary model jointly governed by technical and editorial authority. Core metadata must be structured, centrally governed, and required for approval where it affects search, delivery, or system integration.
Implementation
The baseline metadata model includes dependent dropdowns linking Department Owner to Target Website and Product Title so that uploaders are presented with only relevant downstream options. This reduces naming collisions and separates department names from product titles.
- Department Owner: required anchor field for ownership and downstream filtering.
- Target Website: conditionally filtered based on Department Owner.
- Product Title: conditionally filtered based on Department Owner.
- Asset Type and other standardized descriptors: maintained centrally to keep categories from absorbing classification burden.
- SKU: Required identifier for product-oriented assets.
Authority
- Web Services: field structure, dependencies, required logic
- Digital Communications Coordinator / Copy Editor: vocabulary, labels, taxonomy clarity
- Brand Manager: brand-sensitive classification terms
- DSET: approval of changes with enterprise reporting or integration impact
Governance Rule
- Controlled vocabulary may not be bypassed with free text. Where a dropdown exists, free-text entry shall not be used as a workaround.
- Departments may request additional assistance. Required metadata must be present before approval and publication.
- Communication Services approves vocabulary changes to prevent drift and duplicates. Editorial terms are owned by Communication Services.
- Technical enforcement remains with Web Services.
7. Categories, Portals, and Public Delivery
Policy
Categories support browsing and portal mapping but do not replace security. Public delivery reflects audience experience, brand consistency, and usability—not system structure.
Categories provide a broad grouping for user navigation, while metadata (Department Owner, Target Website, Product Title, and Status) determines which assets are eligible to appear within a given category or portal experience.
Implementation
The category tree should remain shallow, generally no more than two or three levels deep. Categories should emphasize channels, destinations, and high-level topics while relying on metadata filtering for granular product selection. Categories provide a broad grouping for user navigation, while metadata (Department Owner, Target Website, Product Title, and Status) determines which assets are eligible to appear within a given category or portal experience.
- Use an Asset Portal with faceted search when a public destination contains a larger library of downloads and users benefit from filters.
- Use an embedded collection when the need is a smaller curated set of downloads displayed directly within a HubSpot page.
- Portal scope shall be controlled through mapped root-category structures, so public users are constrained to the intended branch without visibility into internal organizations beyond that boundary. Portals must apply metadata filtering in addition to root category scoping to ensure that assets displayed align with the intended department, website, and publication context. Category scoping alone is insufficient to properly govern portal content.
Implementation Responsibility
- Digital Communications Coordinator: category structure and browsing experience
- Brand Manager: UX consistency and design standards
- Digital Communications Coordinator: delivery approach (portal vs embedded collections)
- Web Services: technical implementation and HubSpot integration
Supporting roles:
- Social Media Manager: distribution alignment
- PR/Broadcast/Newsletter Manager: content surfacing and campaign alignment
Governance Rule
Departments may not establish independent portal patterns outside approved Communication Services standards. Public delivery methods must align with enterprise experience standards and HubSpot strategy. Categories must not be used to replicate department structures or ownership boundaries. Department-specific separation and filtering must be achieved through metadata and asset group design rather than category duplication.
8. Naming Conventions and SKU Standards
Policy
Naming is split between technical and editorial governance. File naming and asset identification standards shall be uniform across the DAM and any synchronized delivery environment. Consistent naming supports searchability, cleaner downstream file management, and more predictable web delivery.
Implementation
The file naming formula uses lowercase, hyphen-separated names structured as [department]-[site]-[product title or descriptor]-[version or spec].[extension]. Example patterns include department-specific product files, seasonal graphics, and site-specific documents.
In addition to file naming, a simple internal SKU structure shall be used for product-oriented assets. The recommended format is [Department]-[Product Category Number]-[Sequential Number].
- SKU is the durable identifier when titles are reused, revised, rebranded, or inconsistently typed.
- SKU should be stored as metadata and treated as the primary product reference across DAM and downstream systems.
- SKU governance is managed centrally even when departments request new identifiers.
9. Workflow and Lifecycle Management
Policy
Asset approval is not the full lifecycle. The DAM must govern assets from intake through approval, activation, replacement, archival, and removal in order to remain sustainable and trustworthy.
Implementation
- External or internal contributors upload assets to the appropriate inbound or departmental location.
- Department Coordinators review files, validate metadata, and confirm readiness.
- Approved assets synchronize to HubSpot based on approved integration rules.
- Updated documents are managed as new versions of the existing asset so downstream links remain stable.
- Expiring, obsolete, or superseded assets are reviewed for archival or deletion according to retention rules.
Implementation Responsibility
Lifecycle responsibilities are distributed across functional roles:
- Intake: Department Coordinator
- Editorial review: Copy Editor
- Brand validation: Brand Manager / Graphic Artist
- Visual compliance: Graphic Artist
- Content approval: Digital Communications Coordinator / Communication Services
- Campaign alignment: Event Manager, PR/Broadcast/Newsletter Manager, Social Media Manager
- System lifecycle enforcement: Web Services
Governance Rule
- Lifecycle execution is shared:
- Lifecycle policy technical execution remains under Web Services.
- Content lifecycle policy schedules are created by the Digital Communications Coordinator with each content owner.
- Departments are accountable for maintaining the integrity and intended use of their assets. While assets may be accessible across systems, usage must align with defined metadata ownership and delivery context. Cross-department use should follow governance standards rather than informal reuse.
- Each department must designate a primary coordinator and a backup coordinator.
- Review accountability with the department.
- Seasonal and campaign assets should be reviewed on a scheduled basis so expired public content does not accumulate.
10. HubSpot Integration Governance
Policy
Acquia DAM is the authoritative source for managed assets. HubSpot is the controlled delivery channel for approved assets. Manual file sprawl in HubSpot should be minimized to preserve source-of-truth discipline.
Implementation
- Only assets in Approved status are eligible for synchronization.
- Synchronized files are delivered into designated HubSpot file structures governed by Web Services.
- Version updates should occur in the DAM so downstream links remain intact rather than being replaced ad hoc in HubSpot.
- Developers may use DAM metadata, including SKU, to support dynamic experiences and downstream content relationships where appropriate.
Governance Rule
Changes that affect a synchronized file should originate in the DAM. HubSpot should not become an unmanaged secondary repository for the same assets. Asset usage within HubSpot must follow the intended metadata scope, including Department Owner and Target Website. Users are expected to select assets appropriate to their site and function and not rely on unrestricted visibility within HubSpot as an indicator of permissible use.
HubSpot does not enforce asset visibility or filtering based on department, user role, or metadata. Asset selection and appropriate usage must be governed through structured delivery methods, metadata-driven filtering, and user adherence to governance standards rather than relying on HubSpot file-level permissions.
11. External Contributor Governance
Policy
External contributors shall be limited to controlled submission methods and must not be granted broad visibility into DAM content or structure. Assets submitted by external contributors must meet enterprise metadata, formatting, and quality standards before approval and are subject to the same governance rules as internally produced content prior to inclusion in any portal or downstream system.
Implementation
- Vendors submit assets to isolated inbound sandboxes using restricted uploader permissions.
- Volunteers submit through an unauthenticated submit portal designed only for intake.
- Department Coordinators review submissions, request revisions when needed, and determine readiness for release.
Implementation Responsibility
- Submission requirements and standards: Copy Editor + Brand Manager
- Intake structure: Web Services
- Review workflow and compliance: Digital Communications Coordinator
- Campaign alignment: PR/Broadcast/Newsletter Manager
Governance Rule
Operational review expectations, including turnaround targets and revision handling, should be documented so external asset intake does not become dependent on informal email coordination.
12. Reporting, Compliance, and Continuous Control
Policy
The DAM must be actively monitored to sustain metadata quality, user compliance, and downstream delivery integrity.
Implementation
- Track metadata completeness for approved assets.
- Track approval turnaround and backlog patterns by department.
- Track duplication, stale content, and audit exceptions.
- Track synchronization health for assets pushed to HubSpot.
- Track adoption and reuse indicators that demonstrate platform value.
Compliance
- Metadata completeness: Web Services
- Content quality compliance: Digital Communications Coordinator / Copy Editor
- Brand compliance: Brand Manager
- Asset usage & adoption: PR/Broadcast/Newsletter Manager, Social Media Manager
- Strategic insights: DSET
Governance Rule
Web Services administers enterprise-level monitoring and departments remain accountable for content compliance within their governed operating area.
13. Exception Management
Policy
No department may bypass enterprise standards for security, metadata, taxonomy, public delivery, or synchronization without formal review.
Implementation
- Exception requests should state the business need, the scope, the proposed deviation, and the expected impact.
- Web Services reviews the request for system integrity, user experience, and maintainability.
- Leadership may be consulted for exceptions with broader organizational consequences.
Implementation Responsibility
- Technical exceptions: Web Services review
- Brand/content exceptions: Communication Services Director / Digital Communications Coordinator review
- Enterprise-impacting exceptions: DSET final decision
14. Configuration Blueprint Summary
The following implementation summary preserves the key technical direction from the original Acquia DAM discussion so board-level governance remains visibly connected to the practical operating model.
- Architecture context: 20 departments, 35 websites, and hundreds of products supported by HubSpot synchronization.
- Security model: global brand assets, departmental private groups, and isolated inbound sandboxes.
- Role model: Acquia Admin, Department Coordinator, Vendor, Volunteer, and Public Consumer.
- Metadata model: Department Owner, Target Website, Product Title, plus controlled descriptors and dependent dropdown logic.
- Browsing model: shallow category tree supporting portals and embedded collections.
- Naming model: lowercase, hyphen-separated filenames using department, site, descriptor, and version patterns.
- Workflow model: upload, review, approve, synchronize, and manage version updates through the DAM.
15. Glossary
Acquia Portal: A branded DAM-generated destination showing a curated subset of assets without exposing the full backend.
Asset Group: The primary security boundary controlling which assets a user can view, search, or download.
Asset Type: A metadata classification describing the technical nature of the file, such as image, PDF, video, or logo.
Category Tree: The folder-like navigation structure used for browsing and portal mapping.
Conditional Metadata / Dependent Dropdowns: Rules that filter available metadata options based on a prior field selection.
Controlled Vocabulary: A closed list of approved terms managed centrally to prevent inconsistent tagging.
Embedded Collection: A curated set of assets displayed within another web experience, such as a HubSpot page.
Faceted Search: A filtering experience letting users narrow results by chosen metadata fields.
HubDB: A HubSpot data feature that can support dynamic content relationships downstream.
Inbound Sandbox: An isolated intake location for external contributor submissions pending review.
Root Category: The top-level category boundary used to constrain a view or portal.
Submit Portal: An unauthenticated upload entry point for external contributors without backend access.
16. Closing Position
This framework reflects a joint communication and technology governance model:
- Web Services ensures system integrity and scalability
- Communication Services ensures brand, editorial, and audience alignment
- DSET ensures enterprise-level alignment and final decision authority
This structure ensures that Acquia DAM remains technically sustainable, editorially consistent, and aligned with WELS ministry communication goals.
Configuration Worksheet
Phase — Departments & Ownership (Required First)
Department List
List all departments (target ≈20):
Department Name:
– Primary Coordinator:
– Backup Coordinator:
– Associated Websites:
– Product Types (if applicable):
Example:
Department Name: Missions
– Primary Coordinator:
– Backup Coordinator:
– Associated Websites:
– Product Types:
Phase — Websites & Delivery Targets
Website Inventory
For each site:
Website Name:
– Owning Department:
– Type:
(Public site / campaign site / internal / other)
– Expected asset usage:
(downloads, media library, forms, etc.)
Phase — Product / Content Structure
Product Titles (Controlled Vocabulary)
For each department:
Department:
– Product Titles:
– [Title 1]
– [Title 2]
– [Title 3]
Important: These become dropdown values (not free text)
Asset Types
Asset Types:
– Image
– Video
– Audio
– Logo
– Social Graphic
– Print File
– Other:
Phase — SKU Framework
Product Category Numbering
Department:
– Category Name → Category Number
(e.g., Curriculum → 01)
(e.g., Event Materials → 02)
Phase — Security Model Decisions
Cross-Department Sharing Needs
Shared Asset Use Cases:
– Departments involved:
– Type of shared assets:
– Ownership model:
Phase — Category & Delivery Model
Category Tree (High-Level Only)
Top-Level Categories:
– [Category 1]
– [Category 2]
– [Category 3]
Optional Subcategories:
– Category → Subcategory
Keep this shallow (2–3 levels max).
Portal vs Embedded Delivery
Use Case:
– Portal or Embedded?:
– Target Audience:
– Website:
Phase — Workflow & Lifecycle
Review Expectations
Review turnaround targets:
– Internal uploads:
– Vendor uploads:
– Volunteer uploads:
Lifecycle Rules
Expiration rules:
– Seasonal assets:
– Event assets:
– Evergreen assets:
Archival approach:
– Archive vs Delete?
Phase — External Contributor Setup
Vendor Intake
Vendors:
– Vendor Name:
– Department:
– Upload Types:
Volunteer Intake
Volunteer Submission Types:
– Type of content submitted:
– Departments receiving:
Phase — Reporting Priorities
Tracking Priorities
– Metadata completeness
– Approval turnaround
– Department backlog
– Asset reuse
– Download counts
– HubSpot sync health
– Other:
Q&A
How Categories, Metadata, Security, and Portals Work Together
1. Core Concept
Acquia DAM is made up of separate systems that work together:
- Categories = how assets are organized
- Metadata = how assets are identified and filtered
- Asset Groups = who can see assets
- Upload Profiles = how assets are ingested correctly
- Collections = how assets are selected
- Portals = how assets are presented
2. Categories (Organization Only)
What they are:
- A folder-like structure used for browsing assets
What they do:
- Help users navigate content
- Provide high-level organization
- Allow assets to appear in multiple places without duplication
What they do NOT do:
- Do not control permissions
- Do not drive delivery logic
- Do not replace metadata
Guidelines:
- Keep shallow (2–3 levels)
- Keep stable over time
- Do not use for one-off groupings
3. Metadata (Core Structure)
What it is:
- Structured data assigned to every asset
Examples:
- Department Owner
- Target Website
- Product Title
- Asset Type
- SKU
What it does:
- Powers filtering and search
- Drives HubSpot delivery
- Ensures consistency across departments
Key rule:
- Use controlled dropdowns (not free text)
4. Asset Groups (Security)
What they are:
- The primary security layer in the DAM
What they do:
- Control who can view, search, and download assets
Important:
- If a user does not have access to an asset group, they cannot see the asset
Categories do NOT provide security.
5. Roles (What Users Can Do)
Roles control actions, not visibility.
Examples:
- Upload
- Edit metadata
- Approve assets
- Delete (move to trash)
Permissions and security are enforced through:
- Roles (actions)
- Asset Groups (visibility)
6. Upload Profiles (Data Entry Control)
What they do:
- Preconfigure how assets are uploaded
They control:
- Asset group assignment
- Default metadata
- Expiration dates
- Versioning behavior
Purpose:
- Ensure assets are entered correctly
- Reduce manual errors
- Standardize intake
7. Collections (Selection Layer)
What they are:
- A curated group of assets
What they do:
- Allow you to select specific assets
- Can be manually or dynamically built
Used for:
- Portals
- Sharing
- Embeds
8. Portals (Presentation Layer)
What they are:
- A branded external view of selected assets
How they work:
- Display assets from collections or selected groups
- Provide controlled public or external access
Important:
- Portals do not pull in categories directly
- They display curated or filtered assets
9. How It All Works Together
Step 1 — Asset is uploaded
- Assigned:
- Asset Group (security)
- Metadata (structure)
- Categories (organization)
Step 2 — Asset is organized
- Categories = browsing
- Metadata = filtering
Step 3 — Asset is selected
- Collections or filters identify which assets to use
Step 4 — Asset is delivered
- Portals or HubSpot display the selected assets
10. Key Rules to Remember
- Categories are for navigation only
- Metadata drives filtering and delivery
- Asset Groups control access
- Upload Profiles enforce consistency
- Collections organize selections
- Portals present assets externally
Bottom Line
Do not try to use categories to control delivery or permissions.
Instead:
- Use metadata for structure
- Use asset groups for security
- Use collections for selection
- Use portals for presentation
