Extend the Platform Without Leaving Its Governance
No prebuilt library covers every operation, so teams write scripts, and those scripts end up scattered, unversioned, and outside any control. Symphony AppStore brings extension inside the platform: build a custom node once, publish it to Flexi Flow, reuse it as a governed action, and connect the repositories the code already lives in.
Symphony AppStore is the extensibility layer: a repository of reusable automation apps, scripts, and templates, plus the ability to build custom nodes that run inside Flexi Flow.
Beyond 400+ prebuilt nodes, teams build custom nodes such as Python or SQL scripts that appear directly in the Flexi Flow designer for reuse, catalogue templates in Fastrack for one-input execution, and connect GitHub or Bitbucket through Repo Configuration. Custom logic runs under the same identity, policy, and audit as every other action, so extending the platform never means going around its governance.
Every Platform Hits the Edge of Its Library
A prebuilt catalogue gets an automation platform most of the way, then a real operation needs the one action the library does not have. What happens next decides whether the platform stays governed or quietly leaks control.
The library never covers everything
However large the prebuilt set, some operation always needs a bespoke step, so teams reach for a script the moment the catalogue runs out.
Custom logic escapes the platform
Those scripts run outside the automation platform on a server or a laptop, so they carry none of its identity, approval, or audit and become shadow automation.
Everyone rebuilds the same script
Without a shared, governed place to publish extensions, each team writes its own version of the same logic, so effort is duplicated and quality varies.
Extensions bypass governance
A script that runs outside the platform sidesteps the vault, the roles, and the audit trail, so the more a team extends, the weaker the control becomes.
From a Gap in the Library to a Governed Reusable Node
These are the AppStore patterns, each bringing a custom step inside the platform so it runs under the same governance as a prebuilt node rather than as a script on a server.
Custom Code That Stays Inside the Guardrails
The point of an in-platform AppStore is that extension does not cost control. A custom node is subject to the same governance as any other action Symphony runs.
The engine executes, not the model
A custom node runs through Symphony under defined policy, so extension code executes inside the governed engine rather than as a loose script on a server.
Runs under real identity
A published node carries a real identity mapped to each system's native authorisations when it runs, never a shared or embedded credential.
Credentials from the vault
Custom nodes draw secrets from the vault at runtime like any prebuilt node, so extension code never holds a password or key in its source.
Roles and approvals apply
The same roles, separation of duties, and approval configuration govern custom nodes, so who can publish and run them is controlled.
Versioned in a repository
Repo configuration keeps custom code under GitHub or Bitbucket control, so extensions are reviewed and versioned rather than edited in place.
Audited like any action
Every custom-node execution is logged with identity and outcome, so an extension is as provable to an auditor as a prebuilt step.
From Shadow Scripts to Governed Extensions
The difference is not fewer custom needs, it is a governed home for them, so the one action the library lacks is built once, shared, and run under the same control as the core.
Scripts scattered outside the platform
- Bespoke logic runs as scripts off-platform
- Extensions carry no identity, approval, or audit
- Each team rewrites the same custom step
- Credentials sit inside script source
- Custom code is edited in place, unversioned
- The more teams extend, the less stays controlled
Built once, shared, governed
- Custom nodes published into Flexi Flow
- Extensions run under identity, policy, and audit
- A node built once is reused across teams
- Custom nodes draw credentials from the vault
- Code stays versioned in GitHub or Bitbucket
- Extending the platform keeps it governed
AppStore Extends the Same Governed Engine
A custom node runs on the same engine as every prebuilt action, applying intelligence in three governed modes, so extension gets exactly as much autonomy as the risk allows, and no more.
Rule-based execution
A custom node runs deterministically inside a Template under fixed policy, so bespoke logic executes as a governed step, not a loose script.
Maestro co-pilot
A workflow built from custom nodes can route a decision to Microsoft Teams, so a person approves where judgment is needed.
isAI autonomy
Custom nodes become building blocks that ambient isAI can compose into autonomous, governed responses to known patterns.
Extend Across Every System and Repository
Extension spans the systems an operation touches and the repositories the code lives in, so Symphony AppStore connects both through standard interfaces, with no change to the core.
400+ prebuilt nodes plus custom nodes, all composed in Flexi Flow and governed by Symphony security and governance. AppStore extends the same engine that runs the platform, see the orchestration engine, and its DevOps integrations pair with ITSM automation.
Extensibility With Governance, Not a Loose Script
Frequently Asked Questions
Refer to this section for answers to frequently asked questions related to Symphony AppStore.
What is Symphony AppStore?
Can we build our own custom automation?
Does custom code stay governed?
How does it connect to our code repositories?
Do we still get value without writing any code?
See How Symphony AppStore Extends the Platform
The conversation is exploratory and shaped by the automation walked through during the session, from where the prebuilt library runs out today to how a custom node is built, published, and governed inside Flexi Flow.
Request a Demo