Forge Architectural Patterns

This post outlines various architectural patterns for Forge apps, categorized into methods for extending Atlassian apps, automation, integration without Forge Remotes, integration using Forge Remote, Jira workflow extensions, Jira custom fields, and utility patterns. It details specific patterns within each category, such as 'Surface Information and Controls to Users', 'Update Atlassian App State and Data', 'React to Atlassian App State and Data Changes', 'Define Atlassian App Capabilities', 'Out of the Box Automation', 'Automation Platform Extension', 'Send Data from External Systems to Atlassian Apps (Auth as App/User)', 'Send Data to External System – Atlassian App Initiated/Forge App User Initiated', 'Cross-App Integration', 'Single Remote', 'Customer Hosted Forge Remotes', 'Validating Workflow Transitions with Expressions/Code', 'Responding to Workflow Transitions', 'Define a Custom Field/Type', 'Fetch Custom Field Data on Demand when Editing', 'Push Custom Field Data to Jira', and utility patterns like 'Environment Variables', 'Store Data in Forge Storage Mechanisms/Atlassian App Entities', 'Scheduled Triggers', 'Async Tasks', 'Frontend Events', 'Invoke an App Backend', 'UI Interactivity', 'Run a View Background Script', 'Send Events Within/Between Forge Contexts'.