You have seen how you can customize and define your data environment. When building your Apps over the data based on the Configured Connectors your default data environment is the Production environment. However, for testing or development purposes if you want to limit usage to specific data then in that case you can do so by using the Manage Environment feature available for your Connector.
For the DB Connectors as well as the API Connectors you can configure your environments using the Manage Environment option.
For the Global Connectors for which you need to configure and Manage Accounts, you would need to map the Environments to the Accounts when configuring the Connector.
Configuring Data Environment for Connectors
For the DB connectors and API Connectors you can find the Manage Environments under More Options indicated by the Three Dots (…) against each of the connectors.
Click Manage Environment. Here you can see the list of all the available environments including the custom ones created under your Account Profile > Manage Environments.
Click Configure to add the configuration details for the respective environment, Test connection and click Save.
So now when you have the respective Environment configured, you can make use of the Data from these environments for the specific app depending upon your use case.
Using Data Environment
Whenever you Bind Data from DB Connectors and API Connector for any of your controls, you can see the different Environments that are configured for the connector. This is done using the Manage Environment option that we have seen earlier. In case you have not configured the environment, it is shown as Yet to be configured.
Once you have configured the Data environments for your connectors, these environments can be used when testing your queries. It is useful in scenarios like say where you want to test the query for deleting a record. The record from Prod is not deleted while your testing of the respective query is successfully done from the other test environment. You will find the option to Test in at the bottom of the Query Builder when adding the query.
Further, after your queries are configured, whenever you need to bind data to the connector if you preview the app, you have an option to choose the Data Environment. So the Admin users need not make any changes in the app while developing it but ensure that the production data does not get affected.
So you can view the functioning of your apps with just the test data during preview and ensure that it is responding the way it is expected. For queries like the Delete query in some connectors, the query can be easily tested with the Test or custom data while keeping the Production data intact till it is ready for production.
You can have multiple environments but there would be no duplication of environments.
In the case of global connectors like Twilio, Sendgrid, Slack, and so on, you can have multiple accounts that are created based on your users.
These accounts can be mapped to different environments, which can be useful for cases like restricting data for a certain group of users and so on. You can map the same environment to multiple accounts as well.
Further, you can also set the environment during the course of your action flow steps. You can use the Action Flow > On-screen Actions > Set data environment task to update or set the environment during the process. For more details refer this article here.
Thus with Studio you now have further capabilities to define and use data environments easily at different stages in your app-building process.
Using Environment in Sheets
Depending on the Sheets Permission, users can view Prod, Beta, and Dev filter in sheets. Depending on which filter is selected, corresponding Sheets data can be viewed. Also, LOOKUP of data will happen based on MicroApps Environment. If Prod Environment is selected in Preview then only data from the Prod filter will be seen in the App, the same applies to Beta and Dev environment.
Data in the corresponding filter can be added Manually or when their respective Workflow is executed. For example - A Workflow task that inserts a new row in a Sheet is triggered from Prod Published MicroApp then data will be inserted into Prod filter which is the Live data. Similarly, if Beta Published MicroApp triggers this workflow then data will be inserted into Beta filter. And If this workflow task is triggered from Preview using Dev (Submit On) option then the data will be inserted in Dev filter.
Columns Added when Prod columns is selected, cannot be edited from Beta or Dev filter. This is because of Sheet permissions which is explained below. However, Columns created from the Beta filter can be edited from the Prod filter.
More on this is explained in the Sheet Permission section explained below .
Sheet owner can set Sheet Permission as to who can access this Sheet. This can be set by clicking on the icon (shown below ) next to the Sheet Name under Sheets Tab in Studio.
We already had Can Edit and View Only permission that can be assigned to User for accessing the sheet. Additionally, the Sheet Owner has an option to give Can Edit and View Only permission to Beta environment as well. By default the Can Edit or View Only permission will be assigned to Live / Prod Environment.
Individual share access overrides all general access types. Depending on the access given, different users will have different permission to access the sheets. Below is the list of Permission and its Access rights -
1. Live Environment - Can Edit
User can View and Edit - Prod, Beta and Dev Filter data in Sheet.
2. Live Environment - View Only
User can Only View Prod filter data in Sheet but cannot Edit any data or columns Also, User can View and Edit - Beta and Dev Filter data in Sheet.
3. Beta Environment - Can Edit
User cannot view Prod filter data but can View and Edit - Beta and Dev Filter data in Sheet.
4. Beta Environment - View Only
User cannot view Prod filter data but can Only View Beta filter data in Sheet but cannot Edit any data or columns. Also, Use can View and Edit - Dev Filter data in Sheet.
5. No Access
User cannot open this sheet