Data Center
Jira
Confluence
Advanced Confluence and Jira automation in a regulated industry
In most organisations, processes are helpful guides for moving everyone in the same direction. In organisations bound by regulatory requirements, however, processes can become an inescapable black hole, sucking time out of your teams’ day.
As anyone in a regulated industry knows, when intricate work meets those ultra-specific regulatory requirements, complexity can skyrocket. When a NASDAQ-listed pharmaceutical contract research organisation sought a solution to this headache, they discovered Jira, Confluence, and the power of ScriptRunner automation.
First, the company sought the help of an experienced Atlassian partner. Their work was complex and the regulatory requirements loomed large. They approached Amrut Software, an Atlassian Enterprise Platinum Solution partner based out of India, who took the research organisation’s process complexity and automated it into something slick and manageable.
The ScriptRunner team were lucky enough to speak to four of Amrut’s experts to understand more about this project.
Let’s see how they did it.
The problem
Based in the United States, the research company was developing products within a heavily regulated industry.
The processes they were expected to follow presented three major challenges:
- The processes were very intricate, with templated variations.
- The processes were approval-heavy, with lots of back and forth.
- They were expected to provide high levels of traceability for auditing purposes.
The research organisation had already identified Jira and Confluence as a good solution for unifying some of their processes, for centralising information and for establishing more efficient communication.
Jira was to be utilised for software development, whilst Confluence would play the critical role of managing approvals and documents.
The complexity came in the form of the research organisation’s differing software development lifecycle (SDLC) project templates. Each had distinct purposes and requirements for workflows and approvals as per pharma industry standards.
The team was seeking a new Jira project creation process which needed to be:
- Conditional
- Contextual
- Self-serve, as far as possible
To fulfil industry best practice requirements in Jira means creating at least 94 Jira issues; sometimes more, depending on the project type. These exhaustive and conditional processes create a lot of potential for mistakes and omissions.
“Achieving all of this bespoke and conditional issue creation manually would mean a lot of human effort and carries the risk of error,” said Ashish Birje Head of Delivery, Amrut Software. “ScriptRunner has eliminated both.”
The solution
In brief, Amrut used ScriptRunner to set up advanced Jira and Confluence automations relating to two different types of standard projects in Jira: GxP and non-GxP. GxP projects are those which need to meet best practice standards defined by the pharmaceutical industry. Non-GxP projects are those which do not need to meet these standards–either at all, or at this particular moment in time.
As you might imagine, the requirements for GxP projects versus non-GxP projects were different, needing different templates and with different default configurations.
For each project type, Amrut implemented a complete agile process, including:
- Requirement module (business/user/detailed/user story/use case/epic)
- Development task module
- Test Module
- Defect Module
- Project Status module
- Project Planning module
- Task/Subtask module
- RTM module (Requirement Traceability module)
What about approvals?
To manage the creation of these key project types, a separate project management office (PMO) project was implemented for approvals. A project lead would raise a request (issue) in the central PMO project and await approval. Once their request (issue) was approved; their Jira project and corresponding Confluence space would be automatically created through ScriptRunner.
Each new project gets built out using a pre-set template to maintain consistency, to reduce manual effort, and to reduce the risk of human error. This level of care was especially critical for the research organisation’s GxP projects and ScriptRunner made it possible to achieve the detail and specificity required.
How it works
The PMO project request issue collects details via Jira system fields and custom fields. This information is then used in ScriptRunner automations to trigger the following actions when the project is approved:
- The creation of a project against the appropriate template (GxP or non-GxP),
- The project name and reference key are automatically generated
- The key stakeholders for the newly created project are automatically assigned, such as the business owner, project manager, compliance manager, test lead, and many other pivotal roles
- The access permissions for the new Jira project are set, so that not only are these stakeholders added, each of them is automatically assigned the correct permissions for their part of the project
- The creation of a Confluence space corresponding to the project, also in line with one of two templates. You guessed it: GxP or non-GxP.
- The access permissions for the new Confluence space are automatically handled, adding users and assigning them the appropriate rights.
Having breezed through all of the work listed above behind the scenes, we arrive now at the first manual intervention required by the project owner. At this point, they must manually create their project version in Jira.
Automation steps back in here, triggered by a ScriptRunner for Jira Listener – a feature which waits for certain Jira events and triggers a follow-on action. This listener, when triggered by Jira’s “VersionCreateEvent”, launches the automatic creation of those 94+ requirement issues in the Jira project. At the same time, it creates a Version Page in the project’s Confluence space for traceability.
After project creation
The research organisation’s key challenges included auditing, tracking, and requirement-traceability monitoring (RTM), extending throughout the life of the project and beyond.
Amrut’s experts created several in-life automations to help meet these needs in an efficient and error-free way. Here are two examples:
- Templated Confluence pages with ScriptRunner
There are several issue types in these projects which trigger updates in the Confluence space when created or transitioned. A couple of examples include the “Requirement Document” issue type and the “RTM” issue type.
For instance, when a user creates an issue with the issue type of “Requirement Document”, Amrut built a ScriptRunner post-function which automatically creates a page in the project’s Confluence space. The page is a pre-set template with some static information, plus all of the pertinent information about the auto-created 94 issues plus any other issues that the User may have created in the Jira project since creation. This saves a lot of manual effort and provides accurate moment-in-time data which is needed from an auditing perspective. - Traceability in Confluence, powered by ScriptRunner
Similarly, when an issue with issue type “RTM” is created, the automated setup generates a page in Confluence with full traceability of issues. Each requirement matches to a specific test case used to verify the functionality, or to a document and/or process which was used to satisfy the requirement.
“The document goes into read-only mode after it’s published, too, to maintain the sanctity of the document and make sure that it hasn’t been modified by anyone without a digital signature,” says Vishwajeet Singh, Chief Technology Officer at Amrut.
A note on Atlassian on-premise deployments
These solutions were originally built on Jira and Confluence Server, and Amrut has recently completed a successful migration to Data Center for the client.
Head of Delivery, Ashish Birje had these words of wisdom: “We upgraded them to Data Center because, with the kind of scripting and automation and the custom plug-ins which we had built for them, it needed to be in a supported and highly customisable environment. So they took I would say the sensible decision to migrate to Data Center now, rather than going for that at the very last moment.”
After the project
With their main concerns handled seamlessly with Amrut’s ScriptRunner automations, their client–in true agile fashion–continue to work together with Amrut to make improvements and help the research organisation stay up-to-date on compliance changes.
“Compliance is never a static requirement,” said Ashish. “So the business processes have to change in line with the newer compliance needs. In recent months, we have helped update requirements and implement additional processes and approvals.”
“Whenever these kinds of things come in,” added Aradhana Gupta, Solution and Implementation Head, “when customers start seeing the power of automation, they ask for more things. This is why we always go with more flexible recommendations like ScriptRunner if we’re talking about Jira with a client who wants anything related to process automation.”
“Exactly,” confirmed Vishwajeet. “Everybody who needs some level of automation, I think that the first recommendation would always be ScriptRunner. There are other automation tools which may do it without writing code, but what we ended up realising is that this may be just the tip of the iceberg when customers start asking these kinds of things. So, rather than offering them something and later saying that it will not be able to do what they need in future, we suggest ScriptRunner as the first choice. You can do much more going forward.”
Amrut has more than 50 Atlassian Experts delivering best-in-class IT and business solutions to their clients. The team at Amrut is experienced in navigating complex Jira and Confluence implementations such as this – and using ScriptRunner and other best-in-class plugins like Comala Document Management and Zephyr to make it possible. You can read more about Amrut Software on their website.