Greetings from the Zoho Creator team! We're looking forward to delivering on all the exciting updates we previously announced for you. In this update, we'll be going over:
- Revising developer permissions
- API limitations on workflow looping
- Standardizing link names of subfields in composite fields
- Introducing the Select All option for choices and records in mobile apps
Apart from this, we're working on delivering the following by the end of this month:
- Introducing ManageEngine AppCreator
- Migration of users and permissions from C4 to C5
Previously, when you (the admin) shared apps with developers, they were able to create lookup fields that look up data from other apps (that were not shared with the developer). From now, to ensure data privacy and security for Creator apps, the developers with whom you have shared apps, will no longer have access to such lookup fields in the shared app. In other words, the developer will not be able to add lookup fields from other unshared apps. They can continue to use the lookup fields added by the admin in live mode, but cannot make changes to its field properties. This gives you control over what you can share, and prevents unintended exposure of information.
Also, the developer will not be able to perform the following actions when the shared app contains lookup fields that look up data from other unshared apps:
- Duplicating a form
- Back up and restore
- Import a .ds file
- Publish an app from Sandbox
To enable the developers to edit such lookup fields, you can perform these actions in your scope or share the other apps with the developer.
API limitations on workflow looping
We've recently identified that a particular usage of API requests leads to a cyclical looping of workflow actions, which in turn leads to performance issues. This post is going to explain both the problem and the solutions we've come up with for it.
You can create a workflow with an API request On Load, On User Input, On Validate, and On Success (Add/Update) of a form. It's been observed that some users tend to incorrectly use API calls to add data in the same form or other forms in the same application. This causes a chain of workflows allowing API calls to be repeatedly used in the same manner, creating a loop.
Let's assume Form A triggers a workflow and uses an API call on successful form submission to add another record to the same form. This cycle continues, allowing the workflow to run repeatedly in a loop, with data getting added to the same form endlessly.
Similarly, there are two related forms—Form A and Form B. On successful submission of Form A, an API call is used to add a record in Form B, which in turn hits another API call, submitting another record in Form A and continuing the same pattern, adding records in both the forms over and over again. Both these scenarios prove that they lead to an endless loop of workflows.
This pattern is observed in applications with requirement for repetition of the same action or when multiple actions need to be executed in a sequence.
Limiting API calls
As a measure to stop this looping and avoid the subsequent performance dip, we're limiting the API calls that can be triggered in a workflow action.
Going forward, the following behaviour can be observed:
- Same form: Workflow execution will be limited to one loop, for actions that add records to the same form. That is, the workflow will only be triggered once.
- Related forms: Workflow execution will be limited to three loops for actions that add records to other forms. That is, the workflow will be triggered thrice, allowing records to be added in three forms, after which it will cease to trigger.
For repetitive workflows actions, or if there is a need for multiple actions, users should create functions and use them wherever required. This will avoid the need for unnecessary API requests.
If this doesn't meet your requirement, please write to us at firstname.lastname@example.org. We will assess your requirement and find suitable alternatives.
Composite fields: Link names of subfields
Currently, the link names of the subfields of composite fields, such as name and address, get appended with an incrementing number as we keep adding multiple fields of the same type in a form. For example, if you've added two address fields in the same form, then the link names for the subfields of the second field will be address_line_12, address_line_22, and so on.
We are now fixing this, such that the link names remain the same for all the subfields, irrespective of the number of fields of the same type. In other words, if you have more than one address field in the same form, then the link names for the subfields of the remaining address fields will be address_line_1, address_line_2, and so on. This fix is aimed at improving the readability and subsequent usage of the link names of such fields.
- DC migration will be done from our end to update the subfields' link names and we will keep you updated about the same (migration date and its status).
- Common link names will be used for the subfields of any newly added composite field and also for new Creator signups.
We request users who have used custom link names to make note of the following changes:
- After migration, API requests that contain custom link names for subfields will not work. Instead, you can use their common link names. If you're using Creator Meta APIs to get the subfield link names, then the link name will be automatically changed once the migration is completed.
- If you've used custom link names for subfields anywhere in your app (manually), they won't work post-migration. In such cases, the custom link name should be replaced with the common link name. For example, consider the below cases:
- Using a composite subfield as a query param in:
- Form access URL
- Redirect to (website URL)
- OpenURL (Deluge)
- Using a composite subfield in ZML snippets: The existing ZML snippet component will break, since we don't process a ZML snippet unless it is accessed through live.
Select All option for choices and records in mobile apps
You can now select and deselect all the options in a report using the Select All option in the following cases:
- To select all the choices in multi select fields
- To select all records in a report
This option will be available in the following components:
You can simultaneously select all the choices listed in the bottom slider using the Select All option. This option is supported in the following fields:
- Multi select
- Lookup as multi select (can select the loaded records)
- Lookup as checkbox (can select the loaded records)
When performing bulk actions on records, you can select a maximum of 1,000 records that are displayed in the current report using the Select All option. You can also deselect them by clicking the Deselect All option.
AppCreator - ManageEngine
AppCreator is an application-building platform based on the principles of LCAD (low-code application development). It enables developers to build powerful, custom applications rapidly and launch them on the premises of your organization, rather than at a remote facility (such as cloud). You have complete control over your data as well as the infrastructural set up. Data stays in your private network (intranet), nobody other than your organization's users has access to the information.
AppCreator, with its set of feature-rich low-code tools, helps improve the throughput of IT app development teams—requiring fewer resources for projects and taking up to one-tenth less time than when using traditional methods. This product also empowers IT teams to collaborate, develop, deploy, and maintain applications and workflows while meeting data residency, security, and compliance needs.
These low-code applications encourage citizen developers in their organizations to build robust apps with less code. This helps IT teams focus on business-critical projects while citizen developers create lighter business apps—all the while providing IT teams with the power to administer how the platform is used inside the organization. This will also help in improving tech adoption at organizations, thereby increasing business-IT synergy.
Here's a presentation that outlines the key benefits and features of the platform.
When will AppCreator be available?
We plan to launch AppCreator towards the beginning of June 2022, and we will keep you updated as we move forward.
Here's to kicking off a low-code revolution among ME users in 2022!
Migration of users and permissions from C4 to C5
Last year, we made an announcement regarding the final step of the C5 upgrade process in this post. The final step of this migration will now happen for upgrading the Sharing module (profiles in C4) to the latest version (C5). This upgrade applies to users who are currently using old sharing in C5 and have not yet upgraded to the new sharing. This process will be available in the upcoming weeks and you will be notified via email prior to the migration. You (the admin/developer) of each application has to follow a minimal-step process in order to confirm the upgrade after viewing the preview of each auto-generated permissions set corresponding to the old sharing profiles.
Once all the applications' sharing is upgraded, all the permissions and other configurations for Users and Customer Portal will be upgraded to C5, and the entire upgrade to C5 is now complete. This process will be available in the upcoming weeks and you will be notified via email prior to the migration.
That's all for now!
The Zoho Creator team.