Proposal Summary
This proposal details an all-encompassing approach to connect a Web App with the Jira platform via NetSuite custom records. It incorporates a dual synchronization mechanism real-time and scheduled to ensure optimal management of work items, work requirements, and work efforts. The aim is to create a strong and flexible system for managing projects that meets the needs of different people involved.
Requirement
The Growire Group requires a bi-directional synchronization between Jira and their Web App, leveraging NetSuite. The solution will ensure seamless data flow and integrity for work management, with a design that’s both scalable and adaptable to their operational needs.
Deliverables
Synchronization Flow
The synchronization flow diagram shows how data is exchanged between the Web App and Jira using NetSuite’s Custom Records. The flow chart accurately outlines the directional interplay between custom records, detailing how updates in the Web App’s work tiles trigger changes in Jira, and vice versa, through NetSuite’s structured record pathways.
Work Item & Jira Connection
The connection between Work Item and Jira issues enables bi-directional synchronization. The first phase of development covered synchronization from Jira issues to a custom Work Item record in NetSuite.
In the current phase, we’re focusing on making a script that will update changes from NetSuite Work Item records to Jira issues. This script will be activated when a Work Item record is saved using a User Event Script. This script will only work when creating, editing, or copying records.
This synchronization process is activated whenever a Work Item is created or updated in NetSuite’s custom records, with the necessary updates then applied to corresponding Jira issues. To facilitate this, all mandatory fields for Jira issues must be correctly filled in on the Work Item records.
To address potential synchronization conflicts, a new List/Record field named “Sync Status” will be added to the Work Item records. This field will feature options such as “Update from Jira,” “Update from WR,” and “Sync Completed.”
There are two existing Map/Reduce scripts: one for synchronizing updates from Jira to Work Item records, and the other from the Work Requirement to the Work Item records. When the Jira Sync Map/Reduce script activates the User Event Script, it will set the Sync Status to “Update from Jira,” which prevents the User Event Script from being triggered. Conversely, when the Work Requirement Sync Map/Reduce script activates the User Event Script, it sets the Sync Status to “Update from WR,” allowing the User Event Script to be triggered. If the trigger is from any source other than these Map/Reduce scripts, the User Event Script will still execute. Upon completion of the synchronization process, the User Event Script will update the Sync Status field to “Sync Completed.”
Work Requirement & Work Item Connection
The connection between Work Requirements and Work Items also enables bi-directional synchronization. In the initial development stage, we focused on syncing the creation of Work Requirement records from Work Items in NetSuite.
In this current development phase, we are enhancing the script to include synchronization for edits between Work Item and Work Requirement.
A new Map/Reduce script will be introduced to retrieve recently updated Work Requirement records, and it will specifically create or update Work Item records. The Connection between Work Item and Work Requirement is only the FG square workspace.
To establish the connection between Work Requirement and Work Item, a connection named “GRW007 Sys WorkItem WorkReq Association” record will be created. When creating a Work Requirement, both Super Type and Subtype records will also be established.
Additionally, whenever a new Work Requirement is created, a Requirement Status record will also be generated with the default status of “New” and an Approval Status of “Pending Approval.”
To manage potential synchronization conflicts, we will employ the same solution that was used in the synchronization between Work Item and Jira issues.
Work Effort & Work Item Connection
The connection between Work Effort and Work Item supports bi-directional synchronization. We plan to enhance the User Event script to enable synchronization from Work Item to Work Effort, applicable in both creation and edit scenarios.
A Map/Reduce script will be implemented to fetch recently updated Work Effort records, and it will specifically create or update Work Item records. This synchronization is exclusive to the Growire workspace.
To formalize the relationship between Work Effort and Work Item, a connection named “GRW007 Sys WorkItem WorkEff Association” will be established. Additionally, when a Work Effort is created, both Super Type and Subtype records will be created to maintain structured data integrity.
To manage potential synchronization conflicts, we will employ the same solution that was used in the synchronization between Work Item and Jira issues.
Work Req & Work Effort Connection
This connection is a single-direction sync from Work Requirement to Work Effort. This functionality was established in the initial phase of development. The existing script creates Work Effort Super Type and Subtype records based on the Work Requirement records. To facilitate the connection between the Work Requirement and Work Effort, a fulfilment record is created.
Comments & Attachments Sync
This connection facilitates bi-directional synchronization of comments and attachments between a Web App, Jira, and NetSuite. In the initial development phase, synchronization from Jira to NetSuite was established using a Map/Reduce script.
In the current phase of development, we are introducing a new User Event script designed to create or update comments and attachments from NetSuite to Jira.
For synchronizing comments, the attached flow process will be adhered to when creating records: Attachments will be linked to the Work Requirement Super Type and Work Effort Super Type records.
Currently, this development phase is focusing on a single channel for synchronization.
The comments will solely consist of text content, omitting any styles, tables, etc. Images and files included in the comments will be attached as records in NetSuite. The related “GRW007 Annotation SuperType- Channel” will be determined using the existing data model record connections.
Multiple “GRW007 Annotation SuperType” records labeled as “Comment” along with “GRW007 Annotation Subtyped Comment” records will be associated with the “GRW007 System Work Item” record, reflecting the structure of Jira comments. This phase will consider only the creation and updating of Jira comments, excluding deletion actions.
A script will be used to sync the comments and attachments from the NetSuite custom records to the Jira issues. The working will be opposite sync of the previous phase comments sync.
Error Handling
A custom record will be created for the Error handling process. Should any error arise during the Synchronization Process, the error details will be preserved in the “GRW007 System Error Handling” custom record.
Assumptions
This proposal is based on the following assumptions:
- The field mapping configuration user must be an Admin or Technical person with knowledge of this customization.
- Jira offers all necessary features and APIs to facilitate seamless synchronization for the Jira integration.
- It is crucial for users in Jira to correspondingly possess an GRW007_user custom record in NetSuite associated with the identical email ID.
- User identification is based on email. In Jira accounting preferences, all user preferences should be set to “Anyone”, and Jira user emails must be made public.
- The file size of the attachment should not exceed 10MB.
- Comments must be within 4,000 characters due to the Text Area field limitation.
- Only text details will be considered for syncing comments; tables, code, emojis, and other details will not be synced.
- The attachment file content will be supported within NetSuite only when the Jira returned content type and content matched.
- If a file with the same name already exists, its content will be replaced; a new file will not be created.
- Only create and update actions are considered for the sync. The deleted action was not considered on the current phase.
- This customization is exclusively dependent on custom records and does not depend on NetSuite standard records. The flow is based on the shared Data model.
- The FG Square Web App will be used exclusively for creating requirements, while the Growire workspace will solely handle the creation of Work Effort.
Risks
- Integration issues with the external Jira system, such as problems related to API compatibility, could potentially lead to delays or failures in the NetSuite Jira Sync. Furthermore, any alterations to the Jira API might affect the NetSuite Jira Sync process.
- While the proposal has been formulated based on our analysis, it’s essential to note that more risks may surface only during the development phase. The comments body details sync introduces the possibility of encountering additional risks and challenges in the development process.