Syntax
Last updated
Last updated
We recommend the Camel case naming convention when it comes to naming database fields.
Camel case is the practice of writing phrases without spaces or punctuation, indicating the separation of words with a single capitalized letter, and the first word starting with either case e.g. firstName, lastName, fullDescription.
When linking to other data types follow the upper camel case method which uses an initial uppercase letter e.g. when the User have a field linking to a company data type: Company.
Following this convention you will know that fields starting with uppercase are linked to other data types and those starting out with lowercase letters are fields saved directly on the data type (such as text, numbers, and dates).
Linking field to option sets should start with lowercase.
All inputs elements should follow this syntax:
object.input-type.field e.g. user.input.email should be used to modify the User’s email.
Thanks to this convention searching for the right input will be fast and easy, as you will have multiple points of reference to the input and they are distinguished enough visually to locate them in the conditional dropdowns and field searches.
When building in the app logic most of the time we heavily really on referring to elements that store values.
Read how to centralize the data management on a page in this section.
Ideally, the naming convention makes things easier for the developer to build fast and the most important factor enabling that is searching for the elements from the workflows tab:
Conditional dropdown:
When using a group as a data source its best to keep the same naming conventions for all of the source groups and as well using visual cues that will help us find and locate it faster:
Source: e.g. 🚩 Source - Property
Actionable elements such as buttons, icons, texts, link and other group elements follow this convention: [elementType].[actionType]
e.g btn.createUser, icon.toggleMenu, group.closePopup
Tip: Best to rename things as you go, doing it all at the end of the build is not efficient in our experience.
States should follow the same naming convention as database fields. We recommend using Icon indication to see its representation in actions ⚡️ e.g. ⚡️Product. The icon will act as another visual cue that will help you distinguish between custom states and other input types.
For better organization and reading experience, we recommend naming all custom events workflows with capitalized letters and icons, which play a supporting role in distinguishing between different types of custom events.
Endpoints naming convention should use a dash when using multiple keywords:
e.g. send-email vs sendemail
General tips:
Avoid using jargon e.g. email-update vs ems
No abridging e.g. phone-update vs tel-no
There are exceptions to this rule which is making the API endpoint public. You might consider making the endpoint more cryptic especially if you are not using authentication. (See can read about webhook authentication in this section)
Try to be descriptive when renaming your actions or workflows.
Make a change to the Current User -> Update Current User Personal Data
Scheduled API workflow -> API: Send Invite Email
Make changes to thing... -> Add new Project to Company
