diff --git a/workshop/1_start-an-app.ipynb b/workshop/1_start-an-app.ipynb
index 1db8b988eefa761d754c8509daabe362a90ac652..7dd0f75393dd95d85fbe6bbcacce3cc9067add14 100644
--- a/workshop/1_start-an-app.ipynb
+++ b/workshop/1_start-an-app.ipynb
@@ -21,7 +21,13 @@
     "\n",
     "**Is there any other reason why to run cloudify on the only internally accessible DKRZ HPC?**\n",
     "\n",
-    "If you *cloudify* a virtual dataset prepared as a highly aggregated, analysis-ready dataset, clients can subset from this *one* large aggregated dataset instead of searching the file system."
+    "1. The Zarr-as-a-catalog functionality\n",
+    "\n",
+    "If you *cloudify* a virtual dataset prepared as a highly aggregated, analysis-ready dataset, clients can subset from this *one* large aggregated dataset instead of searching the file system.\n",
+    "\n",
+    "2. The data-as-a-service functionality\n",
+    "\n",
+    "In case you have less disk storage or if you are not sure if a user really needs to retrieve all the data of your specific product, you can just cloudify the workflow and create a virtual representation of the output. The product dataset is displayed *as if it was there* and whenever a chunk is retrieved, the workflow is triggered and the output is generated. This becomes useful when the workflow to generate the product is rather complex so that the users would struggle to execute it theirselves, e.g. if they do not have resources to run the workflow. Having said that, the data providers would spend some resources for the time the virtual dataset is hosted."
    ]
   },
   {