Polarion scripting extends what configuration alone can do. Corbinsoft writes Polarion Velocity scripts for LiveReports and LiveDoc widgets, Polarion workflow scripts for conditions and functions, save hooks, GraalJS and Groovy automation, and Java extensions, each one documented and tested for use in regulated environments.
Polarion covers a great deal through its administration screens: custom fields, workflows, link roles, document templates and queries. Regulated teams usually need a little more. A report that shows exactly what an auditor asked for. A workflow that blocks approval until every linked test has passed. A nightly job that flags risk items nobody has reviewed since the last design change.
Custom code in a validated system also has to be maintainable. Every script we deliver is version-controlled, reviewed, tested on a staging server and documented, so your administrators and your validation team know what it does and why.
Traceability and status reports built in spreadsheets go out of date as soon as they are exported.
Approval rules that live in procedures and not in workflows depend on every user remembering them.
Nashorn was removed from the JDK in Java 15. Older Polarion scripts written for it often need changes to run on GraalJS.
Scripts without source control or documentation become a risk at every upgrade and every audit.
From a single report widget to a packaged Java extension, we pick the lightest technology that meets the requirement.
Polarion Velocity scripts drive custom LiveReport pages and widgets for LiveReports and LiveDocs: traceability matrices, coverage and status tables, release readiness views and document comparisons. We build widgets with parameters, so report authors can reuse them across projects without editing code.
Velocity widget tutorial →Polarion workflow scripts enforce your process at each status transition. Conditions block a transition until rules are met, such as required fields, approved parent items or passed linked tests. Functions act when a transition happens, setting fields, creating linked items or recording approval data.
Workflow scripts tutorial →Save hooks check or adjust a work item every time it is saved, whatever its workflow status. We use them for field consistency checks, derived values and data-quality rules that must hold at all times. Our upcoming Java 21 Save Hook packages this pattern as a reusable starting point.
Java 21 Save Hook →Current Polarion JavaScript runs on GraalJS. We write new scripts in modern JavaScript and migrate older scripts written for Nashorn, replacing patterns GraalJS handles differently, such as access to Java classes through fully qualified names, which becomes Java.type(). Each migrated script is retested before use.
Groovy scripts on the Polarion scheduler handle recurring work: nightly consistency checks, bulk field updates, report generation and housekeeping. We write jobs to be safe to re-run and to log what they changed, so every automated update leaves a record.
For larger needs we build Java extensions on the Polarion SDK, such as custom workflow functions, servlets and widgets, and integrations on the Polarion REST API for CI/CD pipelines, test tools and in-house systems. Our in-house Redline Report Widget is one example of a Polarion add-on we build and maintain.
Redline Report Widget →The same practices apply to a twenty-line workflow condition and to a full Java extension.
Velocity is the Apache template language Polarion uses for LiveReport pages and widgets. A Polarion Velocity script queries work items, documents and baselines through the Polarion API and renders the result as HTML tables, charts or text inside a report or LiveDoc.
A condition decides whether a status transition is allowed. If it fails, the transition is blocked and the user sees a message. A function runs when the transition happens and performs an action, such as setting a field, creating a linked work item or recording a date. Polarion workflow scripts can implement either one.
Often, yes. Nashorn was removed from the JDK in Java 15, and GraalJS handles some Java interoperability differently, for example by requiring Java.type() to access Java classes. We review existing scripts, update the incompatible parts and test them on a staging server before your upgrade.
Scripts suit focused rules and reports that administrators may want to read and adjust. Java extensions suit larger features, heavier processing and code that benefits from compile-time checks and unit tests. We recommend an approach for each requirement and explain the trade-offs.
Every customization has a specification, a source control history, test cases and recorded results. Changes go through your change control process, and the test evidence can be reused in your validation protocols.
Describe the rule or report you need. Our developers will review your configuration and propose an approach.