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 

  1. External or internal contributors upload assets to the appropriate inbound or departmental location. 
  1. Department Coordinators review files, validate metadata, and confirm readiness. 
  1. Approved assets synchronize to HubSpot based on approved integration rules. 
  1. Updated documents are managed as new versions of the existing asset so downstream links remain stable. 
  1. 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: 

– PDF 

– 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
© 2026 Copyright - Wisconsin Evangelical Lutheran Synod. All rights reserved.
All content on listen.wels.net is soley intended for use by those legally vision impaired.