Code for the Codeless

By now you have probably been in a sales meeting, vendor update, or seen the reports. Low/no code is the future. Our service management platforms are so great because we can deploy solutions without needing to write a single line of code. Sometimes, however, knowing a few coding concepts can go a long way to helping you get the best use of your platform. In this article, I will cover some, vendor-agnostic, tips and tricks to help you become a better non-coder by using some principals borrowed from the coding world.

Knowing a few coding concepts can help you get the best use of your service management platform.

Immutability

Something immutable refers to its unchanging nature. When we think of immutability in code, we usually refer to its chance of changing. This is particularly interesting in the world of databases. In a database we usually key our data with some unique identifier. In most modern systems this is likely a globally unique ID (GUID) generated for the item. But if we take the technology out of it and use an example from our own company, this becomes important as we try and query or join data.

If you use your customer record as an example, in a small enough environment, you might think you could get away with using your customer’s name or email address as a good lookup. But what if this data changes? You can end up with denormalized data, or unintended update anomalies if a person changes their name or gets a new email. By using something like a customer ID, or a GUID, we can have a much higher chance that the data will not change. We can also benefit from this approach if we get in a situation where our we have two users with the same name. If our system is querying or joining data by a non-immutable or non-unique data point, we could accidentally get the wrong results.

Stay DRY

In coding, there is a phrase called DRY, which is an acronym for “Don’t Repeat Yourself.” When we use this in the world of code, we mean try to make re-usable code and do not repeat the same things over and over. In a code-less system, you can achieve this by thinking about the re-usability of the things we create.

Imagine you are creating a form for account permissions. It would be best to think of all the ways that form and its fields could be used in the future. Is this form for adding permissions? Is email inbox included? What other items correspond to an “account request?” By thinking this way, you can prevent having to create and manage similar forms, but also make them robust and last longer.

Stay Consistent

Simply put, data in one place should stay consistent across your system, whether this is done through lookups, relationships, foreign keys, or other means. If your system supports ways to join data, it does make sense to try and keep it the same. An often-overlooked issue in systems is similar data across multiple objects/tables. If you have an email field in your ticket record, you want to make sure it is the same size and behaves the same as the email field on your customer record. If there is a mismatch, all sorts of issues can occur.

Everybody Has a Type

The discussion of datatypes, and data structures, and how we store data can start to get real code-y real fast. But understanding some of the fundamentals can help you make the right choices. While this varies by tool, many of our tools support at least the following data types.

• Text & Strings: A text or string data type can be used to store any sort of text, from a small thing like a state or country abbreviation, all the way up to big blobs of text in a knowledge article.
• Numbers & Integers: While you could definitely store a number in a text field, lots of times our tools offer us a data type of number. These can be used for storing user IDs, phone numbers, costing information, or other numerical values. Sometimes our number fields can be whole numbers or decimals, or we might have different types for those.
• Logical/Boolean: These 0 or 1, true or false, yes or no fields allow us to make “checkbox” logic choices. They are great for segmenting out data or for simple questions that we might need to facet our data by when reporting.
• Dates: Another data type that many systems have is a date field. This can Typically hold dates and/or times and let you track all sorts of date-related info on your content.

Plan Everything

The Software Development Lifecycle (SDLC) and associated concepts do not need to be used just for coding. Familiarizing yourself with the flow of the SDLC or similar systems can help you to better plan your updates, features, and content customizations by mapping out your process from requirements gathering and analysis, through design, then development, testing, and of course maintenance of those customizations you are designing. The SDLC is not a perk of being a coder; it can be applied to any project or product you are working on.

An often-overlooked part of planning is planning not only your system and content, but the data. Similar to the DRY concepts discussed earlier, it is important to use only the data that you truly need. If you are not going to use a field in operations, and it is not needed for reporting, you may be able to clean up your data by not including it in your tool at all. Planning out features for the short term and the long term will help you figure out the true need and cost of maintaining a system.

Safety First

Just because you can doesn’t mean you should. A great thing about code-less solutions is they offer flexibility to rapidly create solutions. This can come at a cost though if we don’t take into account best practices for security and compliance. Many of us must follow HIPPA, FERPA, SOCS, and other compliance rules, in addition to information and data security best practices. When rolling out a solution, make sure to still consider those needs.

Imagine: You have a piece of software that you charge users for. So, you create a new charging table where you keep their name and credit card info, and then you run an automatic report that sends those transactions off to the finance team. It was super simple and super risky. That data probably should not be stored in our service management systems. Consider how you are keeping data and if it makes the most sense to keep in your tool. Passwords, Social Security or Tax IDs, Credit Card or Banking info, all come with their own compliance rules and standards. If you want to incorporate those capabilities into your tool, it is best to make sure you know those standards, or do not keep the data at all.

Refactor

A practice in the development world called refactoring refers to going back into your code and improving it. In ITSM, we have a lot of process improvement talk, where we talk about optimizing workflows and making everything else better. When we are coding, it’s the same. Maybe we write something more efficiently; maybe we have learned better ways to do something. In the code-less world, we can still use refactoring to improve things. Look at the customizations or content you have pushed out and do not be afraid to update them.

Learn a Little CodeLet’s face it. Someday you’re going to need to integrate your tool with something else. Many of our tools are powerful code-less platforms; but many of our tools also include APIs that allow us to interface with them through things like REST or SQL. Familiarizing yourself with some more business-aligned coding skillsets like REST APIs and SQL, as well as how to view and process structured data like XML or JSON, will help take you from a code-less pro to a code-less superstar.