Skip to main content
Ask ChatGPT

DAM Rules

DAM Rules enable developers to automate actions in the Digital Asset Management (DAM) platform based on defined conditions. These rules act as event-driven webhooks, designed to execute tasks like updating metadata, linking classifications, or initiating external processes when specific triggers occur. Rules are a powerful way to streamline workflows and enforce consistency in the DAM ecosystem.

How DAM Rules Work​

DAM Rules operate using an If...Then logic. When a defined condition is met (e.g., a record is updated or a file is added), one or more actions are executed automatically. Rules can respond to a variety of triggers, such as:

  • Object changes (e.g., a field is modified, or a record is reclassified).
  • Specific states (e.g., a field contains a particular value).
  • Scheduled events (e.g., daily checks for expired assets).

Rules can be applied to various target objects, including records, files, classifications, and more. Developers can define conditions and actions through the DAM UI or System Studio, depending on the complexity of the rule.

Key Components of DAM Rules​

1. Target Objects​

Rules can act on multiple types of objects in the DAM, such as:

  • Records: Assets and their associated metadata.
  • Files: Digital files within a record.
  • Classifications: Categories and organizational structures within the DAM.
  • Other Object Types: Including file types and custom classifications.

2. Conditions​

Conditions are the "triggers" that define when a rule should execute. Examples include:

  • Object Modifications: A field value changes or a record is reclassified.
  • State Evaluations: A field contains a specific value or meets a comparison condition.
  • Event Occurrences: A file is added, deleted, or previewed.

For example:

  • "Trigger this rule if a record's status is set to 'Archived'."
  • "Execute an action if the file format is '.psd' and a preview has not been created."

3. Actions​

Actions are the tasks performed when conditions are met. These can include:

  • Updating field values.
  • Linking or unlinking classifications.
  • Executing external integrations (via HTTP Request).
  • Generating renditions, previews, or public links for files.
  • Sending email notifications.
  • Applying AI-powered features like image analysis, tagging, or text recognition.

4. Execution Timing​

Rules can execute actions:

  • Immediately: Before the object is saved, allowing real-time updates. Immediate actions may validate changes, ensuring compliance with business rules.
  • Delayed: Scheduled for asynchronous execution via a maintenance job. Delayed actions are useful for long-running processes or changes that do not require validation.

5. Retries​

  • Only certain Actions support retries.

Managing DAM Rules​

Configuring Rules​

Rules are defined through:

  • DAM UI: Ideal for common rules targeting records or files.
  • Admin Studio: Used for advanced or less common rule types.

Rule Structure​

A rule consists of:

  • Name: A unique identifier for the rule.
  • Conditions: Selection criteria determining when the rule triggers.
  • Actions: Tasks executed when conditions are met.
  • Triggering Events: Specify whether the rule triggers upon saving/deleting objects or on a scheduled basis.

Advanced Features​

  • Expression Building: Combine multiple conditions using logical operators (e.g., AND/OR) to form complex triggers.
  • Custom References: Leverage dynamic references for flexible rule logic, such as linking records based on classification IDs or extracting data.

Responding To HTTP Actions​

DAM Rules can have an HTTP Action that makes an HTTP POST request to a configured uri. When this request is received the external system should send back an HTTP response signifying the request has been received, and then close the HTTP connection before the external system processes the data from the request.

HTTP Codes 2xx, 400, and 500, will not trigger a retry on the action.

Examples of Use Cases​

1. Metadata Synchronization​

Trigger: A field value changes on a record.
Action: Update the corresponding IPTC metadata in associated files.

2. Expiring Assets​

Trigger: A record's expiration date is less than 30 days away.
Action: Notify subscribed users via email.

3. AI-Driven Tagging​

Trigger: A new image file is uploaded to a record.
Action: Use Aprimo AI to extract smart tags and update metadata.

4. Classification Updates​

Trigger: A record is linked to a new classification.
Action: Automatically assign a secondary classification based on business rules.

Considerations for Developers​

  • Validation and Security: Immediate actions adhere to the triggering user's permissions and validation rules. Delayed actions bypass validation, providing flexibility for system-level updates.
  • Rule Versioning: Each rule maintains a version history. Delayed actions execute based on the rule version at the time of triggering.
  • Performance Impact: Be cautious when creating rules that apply to large datasets or complex conditions. Test rules in a staging environment before deploying to production.
  • Scheduled Rules: Limited to specific conditions and actions, such as comparing field values or reclassifying assets.
  • Retries: Certain types of Actions have a retries parameter that can determine how many times Aprimo will retry an action. Refer to the Help Documentation available in your Aprimo environment to learn which action types support retries.

For more technical details or examples, consult the platform's Help documentation or contact the support team.