openBuild
  • Introduction
    • Introduction
    • The Framework
    • The Library
    • Release Notes
  • Core Concepts
    • Bubble vs openBuild
    • Responsive Design
      • Repeating groups
      • Advanced Responsiveness
    • Styles
      • Typography
      • Colors
      • Groups & Box Shadow
      • Inputs
      • Buttons
      • Style Variations
      • Changing styles
      • Custom CSS
    • Pages
      • index
      • base-menu
      • base-top
      • base-ribbon
      • base-mobile
      • admin
      • verify
      • styleguide
      • terms
      • login
      • reset_pw
      • privacy
      • 404
      • Menu
      • Base Layouts
  • WORKING WITH the framework
    • Getting Started
    • Navigation
      • Go to page
      • Navigation through custom states
      • Navigation through URL parameters
      • Navigation through URL parameters with Option sets
    • Data & Workflows
      • Custom States
      • Custom Events
      • Working with Reusables
      • CRUD
      • Source Popup
      • Backend Workflows
    • Users and Roles
    • Signup, Login, Password reset
    • Security & Privacy
      • Authenticating endpoints
    • Transactional Email
      • Setup Sendgrid
      • Setup Postmark
    • Alerts and Confirmations
    • Customization
    • Best Practices
      • Syntax
      • Color Coding
  • openBuild Library
    • Chrome Extension
  • Framework Elements
    • Menus
    • Option sets
    • Plugins
    • API Connector
    • User Access Management
    • CRUD Floating Group
    • CRUD Popup
    • Data Table
    • Security Redirect
    • Mail management
    • User Settings
    • Header & Footer
Powered by GitBook
On this page
  1. WORKING WITH the framework
  2. Data & Workflows

CRUD

PreviousWorking with ReusablesNextSource Popup

Last updated 2 years ago

Create, Read, Update and Delete

CRUD is the acronym for CREATE, READ, UPDATE and DELETE. These terms describe the four essential operations for creating and managing persistent data elements.

Custom events are great for repetitive tasks. When you allow users to edit a Thing in multiple places on a page, you can add a 'make a change to' workflow each time you want to save this data. You can imagine that managing multiple workflows could result in errors or, at best, a lot of duplicate work.

Alternatively, you can create a Custom Event. It is a generic workflow that can be triggered or scheduled and use any type of data or no type of data at all.

Instead of having multiple 'make changes to Thing' workflows, you just create one and it's triggered by a custom event.

In this Custom Event we make changes to the User (we pass the user to the custom event and it will be accessible as the 'User'), but we can also use it to reset the form and trigger a Toast notification or edit the User in another way.

Inside the update action, we refer to the inputs where we define that values. Note that we have the ability to define multiple parameters when triggering the Custom event and it means that you don't always have to refer to input but you could also refer to data that you send via Custom event. See the example below:

You should also use this custom event when you create a new Thing. You create the Thing in step 1 and send it to the Custom event in step 2:

This principle applies to all data types and not just only to the User data type.

We are sending the User object that we want to update to the Custom event.
A custom event that updates a User
Make changes to thing is placed inside Custom event
Here the suspended value could be also a dynamic variable. This is just for example purposes.
Example of passing additional value
Create a User and save all the fields in the custom event.