Custom Scripts

Scripts are the lightest-weight entry point into Behavior Extensibility – Python code that runs on the platform server and can be triggered, scheduled, or called from within larger automation flows.

Within the Behavior Extensibility framework, scripts are server-side Python that execute in the context of the Altium 365 platform. Unlike compiled extensions or full workflow automation, scripts are intentionally lightweight: a single file, a defined input/output contract, and a focused purpose. They can be triggered manually, called from hooks, embedded in workflows as steps, or scheduled to run on a recurring basis.

Scripts share the same extensibility infrastructure as checks, hooks, and workflow blocks – they have access to Workspace data, can call external systems, and their results can feed into other parts of the automation pipeline. The difference is scope: a script does one thing, does it cleanly, and can be iterated quickly.

What Scripts Are Used For in this Context

• Targeted automation – a script that runs once when triggered – normalize component parameter values across a library, generate a custom report from Workspace data, push a dataset to an external system after a release. Focused operations that don't need to be wired into the full check or workflow framework.

• Data transformation – scripts are the right tool when data needs to be reshaped between systems – converting Altium data structures into a format an external API expects, or transforming incoming data before it's written into the Workspace. Clean transformation logic in a script is easier to test and maintain than transformation buried inside a larger workflow.

• Policy enforcement, lightweight – for enforcement rules that don't need to run at automatic checkpoints – rules a team lead runs before a milestone review, checks invoked on demand rather than on every commit – a script is more appropriate than a full check registered to a platform event. The overhead of full check infrastructure isn't warranted when the trigger is intentional and manual.

• Building blocks for larger automation – scripts can be called from hooks and workflow blocks, making them reusable units within larger automation. A script that queries an external approved vendor list, for example, can be called from multiple different checks and hooks without duplicating the logic. The script owns the external system interaction; the check or hook owns the policy decision.

Scripts vs Other Behavior Extensibility Primitives

Scripts are not a replacement for checks, hooks, or workflow blocks – they are a complementary primitive with a different role:

Checks are wired to platform validation events and run automatically at defined checkpoints. Scripts run when explicitly invoked.

Hooks respond to platform lifecycle events and fire automatically. Scripts are called deliberately – by a user, by a schedule, or from within another automation primitive.

Workflow blocks are reusable steps inside workflow definitions. Scripts can implement the logic that a workflow block calls, but a script alone is not a workflow step.

Start with a script when the requirement is a focused, on-demand or scheduled operation. Move the logic into a check or hook when it needs to run automatically at platform events. Wrap it in a workflow block when it needs to be composed into structured multi-step processes.

Maintenance and Iteration

Scripts are Python files – they live in version control like any other code. Because they are interpreted and don't require a build step, iteration is fast: change the script, deploy, test. This makes scripts the right starting point when the exact requirements aren't fully defined yet, or when the logic needs to evolve quickly in response to real usage.

A script that starts as a one-person utility often grows into shared team infrastructure. When a script reaches that point – used by multiple people, covering a critical process, expected to be reliable – it's worth investing in proper structure: input validation, error handling, logging, and potentially migration into a more formal check or hook if automatic triggering becomes needed.