In order to develop scripts, please make sure you have read and understood Generated File and Script Anatomy article. 


Develop locally

In order to develop locally, you will need to create a client by passing the parameters and token, because we can't control the scripts locally. Follow the below steps to develop locally.

  1. Install the latest kes python client locally. Follow this article: How to use Python & Kes.
  2. Download the generated file from KES by following the Generated File article.
  3. Create a folder locally or in your IDE where you can place your generated files.
  4. Create a python file main.py at the root of your folder. This main.py will be the entry point of your scripts.
  5. You can also place a requirements.txt file which can install not commonly used packages and use it when running your scripts in KES system.
  6. To develop scripts locally you will always need to obtain a script token and use it to create a client. You can obtain a script token by following How to use Python & Kes.
  7. You will also need to specify which activity you are accessing locally. 
  8. Once you have developed and tested the script locally, you might want to attach the script to KES, so that it is available for all the users access the activity.

You will need to keep in mind that running scripts locally is a little different than running scripts in KES. When you test locally, you will need to specify the activity & token. But when you are running in KES and have uploaded the script to a template, and want to access only activity that the user running the script has access to, then you don't need to pass any token, but you might have to specify activity if the script is accessing activity different from where it is being run.


So the rule of thumb when developing/uploading script to KES and running from KES is : 

  • Locally you will always need to specify token, environment & activities for which you are running the script.
  • If the script is going to access only the activities which the user has access, then don't need to pass any token, we will authenticate the user because we know what the user has access to.
  • If the script is going to be run only for a single activity where it is attached through a template or directly, then you don't need to pass any activity_id or token. We can identify from where the script is being run.
  • If the script is going to read/update other activities within a project or outside then you need to provide the token and activity Id.
  • You can mix and match and create several clients within your scripts in order to accomplish a more complex task and updates/reads across activities.


There are two places where you can attach a script.

In a template ->

  • When you attach a script to a template, the script is automatically available to all the activities which are created using that template and the version for which the script is attached.
  • So, let's say you created a script for Template A and version 3, so any activity which is added to a project using that template and version will have the script.
  • Now you have modified the template and published it again, so now the latest version is 4 and if you add any activity for version 4, you won't see the scripts in your activity. But you will still find the script for an activity which were added earlier for version 3.
  • So, you will have to modify your scripts by updating the generated script and re-uploading the scripts zip file to a template.
  • A script for a template can only be attached to a published template.
  • You can attach a script from below option menu.

In an activity ->

  • The user can always attach a script even if there is already a script from a template.
  • The script attached to an activity will only be available to run from that particular activity.
  • You can attach a script from inside an activity.

Currently, we don't allow to download the scripts, once it is attached.


The user can run a script inside an activity.