Simplifying Document Access Across Departments with Jira, AWS Lambda, and Google Drive!

Data must be stored in secure vaults, yet remain accessible to authorised users.

Teams often work in isolation, creating data silos, manual tasks, and inefficient processes. To address these issues, Credit Saison India’s data-tech team continuously simplifies and streamlines data workflows.

One major issue that we recently faced was that different teams consume documents uploaded by loan applicants for various purposes. For instance, loan agreement may be needed by the legal team for sending notices to customers or the operations team may need the KYC documents for verifying certain information. More often than not, these files are needed in bulk– and members of different teams spend hours and days downloading these files from our internal web-portal, one app form and one applicant at a time.

Fig: Internal portal from which documents can be downloaded 1 at a time.

Hence the question arose- Why spend hundreds of hours on manual tasks when they can be automated with ease? There’s an aspect of security here, but we shall come to that later.

Fig: Custom Jira Ticket

Given that most teams in our company are already using Jira for different projects and automations, we decided to create a custom Jira project instead of creating a new UI or a Web App.

The Architecture

We wanted to keep the architecture simple and ensure that our solution can scale based on the amount of data that we needed to process.

Let’s quickly walk through the 3 parts of the puzzle-

1. Custom jira ticket- We created a custom jira ticket, where one can select the environment (test or production), the date of the file and attach a CSV file for all the loan ids.
2. Step Function- We initially planned to use a lambda to fetch the files for all the app forms. Later we realised that there could be scenarios where someone has uploaded a CSV with 10,000 app form ids causing the AWS Lambda to time out. Hence we created a map state in a step function which would loop over all the app form ids (multiple at a time via >1 concurrency), and get files for each app form and dump them in the Google Drive.
3. Shared Drive in Google Drive- This is where we dumped the files for each app form. We would create a folder with the name of the app form, and dump all the files related to it in the same folder.

Fig: Workflow for getting different files

There are 2 steps in the Jira ticket-

Fig: Steps in Jira Project

1. Creator- Someone has to create the ticket and add values for all the parameters. He or she will also need to upload a CSV with just one column containing a list of app forms. There’s only a limited number of people who are given access to the project- not everyone in the company has the permission to create tickets. This list can be updated and folks can be added or removed in the future.
2. Approver- The person who creates the ticket has to tag an approver. The approver has to be someone from a set list. Whoever is tagged as the approver has to go through the details of the ticket as well as the attachment and then decide whether to “Approve” or “Reject” the ticket. If approved, the ticket moves to the next stage and automatically invokes an AWS Lambda via a REST API call.

Why Google Drive?

While we have previously shared files with both internal and external teams using signed url of files sitting in AWS S3 buckets, for this project, we specifically decided to go with a shared Google drive.
The reason behind this were multiple-

1. Longer Data Retention- Signed URL generated in AWS for S3 bucket objects can have a maximum validation of 7 days. For some files, access needs to be given for a longer period of time.
2. Granular Access- Signed URLs can only be used to download the files, whereas here we needed to provide view access to some and download to others.
3. Better Security- While an AWS signed URL could get misplaced and used by someone who isn’t supposed to be using it, Google shared drive access is given only to specific individuals and cannot be shared by them.

What about security?

Remember when we said we will speak about security later? We weren’t trying to skip it. We will be discussing all the security-concerns that we addressed while working on this project.

Fig: Access Control Lists that need to be maintained

1. Jira Access- We curated 2 lists of users for Jira access. 1st list for folks who would be able to create a ticket in this project. 2nd list for managers who would be able to approve those tickets.
2. Google Drive Access- We created 2 lists for Google drive access as well. One for those who would be having read only access for the Google Drive and the second for those who can also download or upload files.
3. No Sharing Options- While we are providing access to the shared drive, there’s no option for anyone to share documents with others.
4. Data Archival- For every project where we adopted this architecture, we added some fail safes. For instance we delete files from the shared google drive after ‘n’ number of days. This ’n’ can have a different value for each project.
5. Audit Records- Being a financial entity, we understand that it’s not just important to control who has access to which data, but also to keep a record of who fetched what. Because of the way we have setup our custom Jira project, we can easily check what documents were requested by each user and who approved each ticket.

While tech teams often focus on clients, business processes, and revenue growth, improving internal workflows — especially those enhancing data access and usability — can deliver long-term, compounding benefits. By using technology to streamline manual tasks, teams become more efficient, ultimately boosting your bottom line.