This article was written by Joël Theunis, Senior Collaboration Engineer at Devoteam G Cloud Belgium

In this article, we’ll discuss the 10 steps you can take to launch a successful Apps Script solution.

Google Apps Script is the cloud-based SaaS development environment, embedded in Google Workspace, which enables you to automate (script) common tasks within the Workspace environment. It, additionally, enables you to exchange data with 3th-party solutions and integrates with the Appsheet (no-code) environment.

1. Detection

The most obvious question you should ask to detect a possible use case: 

Is there a repetitive task for which one/more of the following statements is true?

• I don’t like to do it (boring, not-challenging, not-core-business, not efficient)
• it is time-consuming
• it is complex
• it is sensitive to errors  
• Can I use one or more Google Workspace apps to complete it?

2. Process analysis

The next question you have to ask yourself is : 

What will be the ROI (return-on-investment) if I automate this task? 

To calculate the ROI, you can investigate the possible time gain. Don’t forget to add the cost of errors or mistakes to the calculation. This will give you a clear overview of the potential ROI of your project. This will allow you and your team to make the go / no-go decision. If it’s a “go”, you can use the ROI calculation to set a clear budget (constraint) for this project.

IN → WHO, WHEN, WHY → OUT

The next step is analysing the process (the actions) you want to automate. Describe all the inputs and outputs, who has to execute the process and when. Be critical and don’t forget to ask: “Why?” to make sure all actions are (still) valid and needed.

3. Process optimization

In this step, additional information needs to be gathered. Opportunities to optimize the surrounding process(es) should be investigated: examine the (technical) details of the process or task you want to automate and check if the previous and or next step(s) or that task can be included aswell. To see if you have included all surrounding processes, you can start the investigation with the following questions: 

• Where are inputs coming from?
• What is the output used for?
• What triggers the execution?
• Can we include previous/following steps in the workflow?

It is important to detect any possible exceptions in this step.

4. Process automation design

Based on the gathered information we can now design the process automation in an environment without constraints:

input – process – output

The design must include security considerations/constraints to be taken into account and provide a scope for the detected exceptions.

5. Proof of concept (PoC)

This step is to verify, prove, and obtain approval for this technology (Apps Script). You check if the technology is usable to execute the process as needed and to ask yourself if it will be able to give the expected outcome for the targeted audience.

6. Parameterisation

When the PoC is approved it needs to be made usable for the end-user. You have to define elements like this: 

• How will it be accessible for the user? What’s the UI (user interface) the end-user will use?
• What can/will change in the environment?
• Which exceptions need to be handled?

The answer to these questions will provide the information needed to design, set up and implement parameters UI(-elements), if any. This determines what should be tweakable (by the user or admin) to make the solution fit and adaptable to end-users needs without the interaction of a developer.

At this stage also exception and error handling needs to be foreseen. Define when and how you will handle these errors. Optional logging and traceability requirements should be considered and noted.

7. Lifecycle

At this stage, the lifecycle of both the data and the functionality is assessed so it can be taken into account during the development. Define these lifecycle elements: 

• Data life cycle: how long do you need to keep the data? When does data become invalid? Do you need procedures to clean/archive/backup the data?
• Versioning: is there a need to keep track of changes in the functionality, for instance when they are related to data manipulation? Are there any additional future functionalities expected?

8. Distribution

There are different possibilities to “distribute” or “present” the functionality to the end-user:

• editor (document/template) bound
• as a library
• as a standalone (web) application
• Appsheet integrated
• editor addon (private/public)
• Workspace addon (private/public)

The final decision on which option is best will be clear when the previous steps are executed. The options can/will be limited by previous choices but should not be requisite. For complex solutions, a hybrid of different options is more common than an exception.

9. Development

Some development started during step 5, but the main and final part should be done after all of the previous steps were taken. The reason? If the previous steps are taken into account or are done after the development this will endanger the development effort already spent and potential require a complete rework or (worst case) need to be thrown in the bin.

10. Support & Maintenance setup

It is important to design, set up and have a budget ready for:

• documentation (of the code and the functionality)
• support channels (for the end-users)
• self-service procedure (for the users/admin)

This will ensure the functionality will be maintainable in an ever-changing environment.

What’s next

After implementation, and adding regular intervals, we return to Step 1 and check for:

• possible improvements
• exception handling
• bug fixes
• extra functionalities

Conclusion

Following these 10 steps should assist you in creating a long-living solution to automate your tasks without creating more overhead as you could gain in time-saving.

Are you interested to learn more about Apps Script? Contact one of our experts for help. We can provide a custom solution as a service.