Business Process Automation

There are literally a dozen new "no-code" platforms popping up almost every week - and a good many of them are emphasizing that they can help with "Business Process Automation". So what is Business Process Automation? Basically, BPA is the act of computerizing one of the normal functions or "workflows" in a business (such as Accounts Payable, Accounts Receivable, purchasing, or new employee onboarding) that are currently being done as a series of separate steps. In order to automate one of those processes you have to start by defining the entire chain of events that are involved, including which employees are responsible for which tasks and what each person's options are at a given point in the process. For example, new employee onboarding can be complex, requiring the cooperation of many different people in the organization. Typical steps in the process include:

• Prepare a workplace for the new employee, equipped with a phone, computer, office supplies, and any other items the person may need.
• Set up the new person's internal email and messaging systems.
• Make sure the new hire's supervisor and fellow workers are notified about when the person will be starting work and what duties he or she will be performing.
• Explain the terms of the employment contract to the new hire and secure the person's signature.
• HR will need to have the new hire fill out a Form W-4 for income tax withholding and a Form I-9 to verify the person's identity and right to work in the United States. In addition, if the new hire wants to be paid by direct deposit HR will need to gather that information along with an acceptance form for any voluntary deductions the person elects to have deducted from his or her pay. 
• Set up a training plan and a schedule for training sessions.
•  Present the new hire with a copy of the employee handbook.
• List any equipment, tools or inventory items given to the new employee and obtain the person's signed agreement as to what items were issued.
• Schedule any previously agreed on drug testing.
• Have the person sign any non-disclosure or non-compete forms required by the company.
• (Additional onboarding tasks)

This is only a partial list of the items that may be included in bringing in a new employee, so you can see why doing all this manually can be difficult to manage. Encapsulating everything into an app can streamline the process by ensuring all steps are followed and documented and all persons that need to be involved are notified automatically when there's a task they need to perform. The app can also be designed to allow for alternatives if a particular person is missing or if there's an unusual circumstance, such as the person is being brought on as a freelancer.

Integrating a workflow automation procedure with other systems can also be a big help in keeping track of things. For instance, I did some work a few years ago for a large company that had a dozen tire stores with several mechanics at each store. The company issued certain tools and equipment to each mechanic and employees were required to return those items when they left. Since there was a high turnover, making sure of what had been issued and what had been returned was a time-consuming process. Integrating the inventory function into automated onboarding and exit processes would have simplified the record-keeping required by making it a standard part of the handling of new hires and terminated employees.

If you need to create a BPA system you can definitely do that with a no-code app. With the recent surge in interest in process automation you can build BPA apps on almost any no-code platform these days. Just do a little research to see what options each platform offers  - and to give yourself a head start, look to see if a particular platform has a template that fits your needs. I'll also be doing more posts about automation apps here on the blog in the near future.

No-Code Websites and Mobile Apps

Of course apps aren't the only thing users can create without knowing how to code. There are a number of popular website hosting platforms like Squarespace, Shopify and Wix that allow you to build a website without doing any coding. You can create an attractive, responsive and feature-rich website with any of them, but your're limited in how you can interact with your users.

With a website, your users have to remember your URL and navigate to it using a web browser. How can you increase your engagement with them? The simplest way is to build a mobile app from your website. Mobile apps have several advantages over websites – they're right there on the user's home page where one click opens up the app, plus you can send them push notifications occasionally to keep them informed about your business.

You can't create a mobile app from your website directly, but there are a number of no-code platforms like Appy Pie or PandaSuite that can do the job for you. They can convert your website into an Android and iOS app which includes features like push notifications, coupons, and the ability to receive in-app payments.

Even if you don't have an app you want to create, no-code platforms can help you to connect with your audience and extend your reach beyond your website. That's another good reason to learn more about the “no-code movement”.

Coming Soon - A New No-Code Book

Coming soon on Amazon - a new guide to no-code app development: Learn “No Code” App Building (Be Your Own Programmer). 

Types of No-Code Applications

There's a wide range of applications that can be built using no-code platforms, but they all fall into the following categories: web apps, mobile web apps, native apps, hybrid apps, and progressive web apps. So, how do you decide which type of app to build? It depends primarily on your target audience and the features you need. In order to give you an idea of how the different categories compare, here a few basic facts about each type of app:

Web Apps

• Web apps are intended primarily for use on desktop computers. They're normally constructed using a combination of HTML, HTML5, CSS, and JavaScript elements and often work in conjunction with an online database.

• The app (and its data) are stored on a web server so you need a browser and an active network connection to access the application. To provide offline access you have to use an SQL-based database API to store data locally and an offline application HTTP cache to make the application available even when the user isn't online. 

• Web apps can be accessed from a mobile device just by directing the device's browser to the app's URL. How the app appears on a particular device and operating system (Android or iOS) depends on how "responsive" the app is - that is, whether it automatically adjusts for different screen sizes and layouts. In some cases a website may provide two versions of a web app - one for desktop viewing and one specially designed for viewing on a mobile device.

• You don't need to worry about whether or not you have the latest version of a web app, since they reside on a web server and everyone accessing the application is automatically using the latest (and only) version of the program.

• If you access a web app from a mobile device, the app isn't going to load and operate as quickly and efficiently as a true mobile version that's installed directly on the device. 

• Web apps don't have to be approved by an app store, so you can launch them faster than mobile apps. However, your app may be harder for potential customers to find since it's not on display in a store.

Native Mobile Apps

• Native apps are built for a specific operating system (Android, iOS or Windows) and are optimized to run as efficiently as possible on that operating system. No-code platforms such as AppyPie, Adalo, GoodBarber, Thunkable, and others let you build mobile apps for Android or Apple and get them into Apple App Store or Google Play Store.

• Because they're installed directly from an app store onto a particular mobile device, mobile apps can access any of that device's built-in functions: GPS, accelerometer, camera, etc.).

• Native apps can work offline since the app lives on the mobile device and doesn't need to connect to a network in order to function.

• Users can feel secure using native apps since the apps have to be checked and approved by the Apple or Google app store before they're made available for download. 

• There is a cost involved in doing business through the app stores.  Google Play Store has a one-time charge of $25 to upload your apps to the store, and they take 30% of whatever price a customer pays for your app as a commission. To use the Apple App Store you have to pay a $99 fee each year, and Apple also takes a commission of 30% of the price the customer pays to buy your app. Note: Apple recently announced that they're cutting their commission rate to 15% for small developers.

Hybrid Apps

• Hybrid apps are basically web apps enclosed in a wrapper that allows them to be installed on mobile devices through an app store, the same as native apps. You can create hybrid mobile apps on no-code and low-code platforms like Appery, AppyPie, and Mendix. 

• Unlike native apps, hybrid apps can run on both Android and Apple operating systems, so you only need to create one version that can be uploaded into both Android and Apple stores.

• Since hybrid apps are actually web apps they generally run slightly slower on mobile devices than native apps.

• While there are a few no-code/low-code platforms that allow you to build hybrid apps, Progressive Web Apps (PWAs) are the becoming the alternative to native mobile apps on many no-code platforms.

Progressive Web Apps

• PWAs, like web apps, are built using elements like HTML, CSS, and JavaScript. More and more no-code development platforms are providing users with the ability to create PWAs.

• Progressive web apps look like native apps but, like regular web applications, they live on web servers rather than being installed directly on a mobile device. PWAs can be installed on your device's home screen by linking the app's icon to its web address.

• Again, like regular web apps, PWAs require a network connection in order to reach the website where they're stored. However, unlike regular web apps, PWAs can operate offline by using a technology called "Service Workers". Service Workers caches data from the website, saves it on your device and displays an icon marking the location where the data is stored.

• Although PWAs share many of the characteristics of a native app, they can only make use of those functions on the mobile device that are supported by web browsers (such as video or audio recording).

Push Notifications: Using Them in Your No-Code App

To be clear, push notifications are messages that pop up on a mobile device. They look like SMS text messages and mobile alerts, but they only go out to users who have installed your app. Push notifications differ from in-app messages in that the user sees push notifications even if your app isn't open on their device (they typically pop up on the user's lock screen), while users only see in-app messages once they open your app.

Why use them in your app? For a couple of reasons. If you're a developer looking to sell your apps, push notifications give you a chance to communicate directly with your customers. Let them know about special features in your app, upcoming events, or new products and thank them for choosing your app. Or if you're part of a development team or you're using the app in a company setting and you need to send and receive messages from other team members or other people in the company, push notifications can handle that too. 

So, what do the notifications sent to customers or other users look like? Web push notifications normally include these elements:

• Title (such as your company or app name).
• Message (brief text).
• An icon, emoji, or image (often used to supplement the message).
• A Call To Action (such as a clickable link or button).

For example, the title might be "Mastering No-Code", with a message "Check out our new universal mobile app template", an image of a cell phone screen with an app running, and a CTA consisting of a link to this blog. 

How you create and manage push notifications depends on the platform you're using and the process can be fairly complicated. In most cases, implementing push notifications is going to require using a plug-in (or "add-on") specifically designed for the job. For example, if you built your app on Bubble you can use the "Firebase Cloud Messaging" plug-in (which costs $12 per application). Most other no-code platforms will have one or more similar plug-ins available and a few may even have push notifications integrated into the platform.

Caspio's Free Patient Portal Template

If you have a need for a comprehensive online patient management app, Caspio has a no-code template that could be your answer. The free template includes a public view, a patient view, and a physician view, and a customizable database that can be stored on Caspio's platform, which is HIPAA (Health Insurance Portability and Accountability Act) compliant. 

Features include:

• New patients can fill out a medical history form online.
• Patients are able to view a list of their prior visits to the facility, along with the results of that visit.
• Patients are able to view messages sent by their doctor or the medical staff.
• Patients are also able to update their profile information at any time.
• Physicians and staff can view a list of the patients (active or inactive) by doctor, including their medical status, insurance carrier and policy number,  and email address, along with details of their medical history, previous visits, and vital signs taken during each visit.
• Physicians and staff members can leave messages for patients, regarding scheduled appointments, medication, advice on treatment, or other information relating to patient care. 

Caspio even suggests some enhancements you could add to the template,  such as email alerts to patients (regarding test results, changes in medicine, etc.) and an appointment calendar that would allow patients to sign up for an appointment on their own. 

One other thing I like about this template is its flexibility. With a few changes you could make this work for a number of situations where you have visitors, members, and administrators. For example, if you need an app to manage a volunteer organization, you could modify the template to handle visitors who might be interested in volunteering, actual volunteers, and supervisors or project managers. Messages could be sent to specific volunteers regarding the projects they're working on, and you could keep a history of which projects each volunteer has worked on and how many hours each one has contributed.

If you're interested, there's a six part tutorial on building the template available on YouTube:

https://www.youtube.com/results?search_query=caspio+patient+portal 

Building a Simple Mobile App on Glide

Glide (www.glideapps.com) specializes in providing users with a quick and easy way to turn their Google Sheets spreadsheet into a mobile app. I should mention that Glide has now added the option to use their internal data tables instead of Sheets, but I decided to go ahead and build my app with Google Sheets as my data source. The app itself is a basic reminder application, to keep track of appointments, projects, articles, or anything that I might want to explore further. Creating the app went like this: 

• I went to my Google Sheets account, created a blank spreadsheet, and added six fields: Keywords, date added, target date, description, location/source, and image. The "keywords" field contains words that relate to specific types of items in the database: blog posts, no-code platforms and tools, sports, space exploration, medical technology, volunteer projects, animal rescue, and so on. The "date added" is self-explanatory, "target date" refers to something like a deadline date or the date of an appointment, "location/source" could be a URL, business address, or the name of a contact, and the "image" field could be a picture of a product, a map, or a screenshot of an app.
• Once the spreadsheet was set up, I entered several sample records in order to have some data for Glide to work with: 
  
  
  
• Next, I signed up for a free account on Glide. A free account allows you to create mobile apps, but you're limited to 500 rows of data and 1,000 sheet updates (changes to your Google Sheets spreadsheet), plus your app is public (open to everyone).
• After I signed up the "new app" screen displayed (you can either click the "+" sign to start from scratch or you can choose to start from a template): 
  
  
  
• I clicked the plus sign, which brought up the option to use Google Sheets as my data source or use Glide's new internal tables: 

• Next, I selected "Google Sheets" as my data source, clicked "Continue", and chose "ReminderDB" as the spreadsheet I wanted to use. Glide connected to my spreadsheet, formatted my app to fit the sample data, and displayed the  result on the design canvas: 
  
  
  
• Clicking on any of the 3 reminders on this screen (the "List" screen), automatically displayed the "Details" screen for that reminder: 
  
  
  
• Glide added basic navigation automatically (note the back arrow on the details screen), along with a search box. And by checking a couple of boxes you can allow users to edit and/or delete entries. Clicking the pencil icon on the details screen brings up the "edit" screen, which also has a button that lets you delete the item being edited: 
  
  
  
• In addition, there were some other options that could be added easily, such as grouping the list items by a particular data field. 
• You can also add various "actions" to the app, such as composing an email, opening a hyperlink, playing a sound, and so on.

Overall, it was easy to build a simple app with Glide, and there were a number of other things I could have done with it. However, I stopped at this point for two reasons: 

•  One, the responsiveness of the app isn't great at times (which is understandable since it's constantly accessing an outside source in Google Sheets).
• Two, using Glide's internal tables would avoid the responsiveness problem, but if you have a considerable amount of existing data there's no straight-forward way (at least that I could find) to import that data into Glide's tables.

I did like working with Glide though, and once they address the import problem it would be one of my top choices for building mobile apps.