Welcome to part 3 of the Builder series. In this video, we’ll discuss a few technical details to be aware of before you build your app on the Now Platform. Don’t worry, we won’t get too technical. These are just a few things which—if done right—can make the maintenance of your app easier in the future. When you build an app, some steps you take will be irreversible. You need to be aware of these so that you
can plan in advance and make the right decisions. The first decision is the scope of the application. A scope is basically a container to keep your
application components in. When you create an app, you can create it
in a private scope, called a scoped app... ... or in the global scope, called a global app. Scoped apps get extra functionality for managing
development, deploying the app, and data security. By default, all apps are created in a private scope... ... because typically citizen developers, or builders, should work with scoped apps rather than the global app. And here’s something important to remember: After an app is created, you cannot switch from a scoped app to a global app or vice versa. Proof of concept (or PoC) apps can be built
in a personal developer instance. You can get a personal developer instance
from the ServiceNow Developer site at developer.servicenow.com. These instances are named with numbers, for example, dev12345.service-now.com. Just be aware not to import PoC apps from your developer instance into your organization’s instance. Instead, you’ll need to rebuild the app there. Your app includes information indicating where it was built. If you bring the app over from your personal
developer instance... ... life will be a lot harder when you try to get that app into production. On the other hand, a developer instance is
perfect for experimenting with the platform tools... ... and learning about the latest features. For example, follow along with this video
series to build your own safety issue app. Apps that your organization will actually
use (for example, production apps)... ... should be created in your organization’s development instance so that the app can follow your organization’s testing and deployment process. See your ServiceNow System Administrator for
more details... ... about which instance to use for an app that will eventually be deployed into your organization’s production instance. Now let’s talk about naming your app. Based on your app’s display name, for example “Safety”... ... the Now Platform suggests a default (internal) name called the app scope. The app scope takes this format: x_snc_safety
where “snc” is the company code for your organization... ... and “safety” is based on the name you gave the app. Everything you create within your app will inherit that scope name, so it’s important to give it some thought. The display name of the app can always be
changed, but the scope name cannot. After your app is created, you’ll likely
create new tables and fields for it. Tables and fields both have labels, displayed in your browser and mobile interface, as well as internal database names. Like the app name, labels can be edited and
even translated into different languages later... ... but internal database names can only be edited
at the time they’re created. For tables, a label like “Safety issues” may look nice at first... ... but it produces a name of x_snc_safety_safety_issues. For consistency, use singular table names. The system automatically produces plural labels
where needed. Also, avoid redundancy between the scope and
table name. Luke’s scope is x_snc_safety, so creating
a table that also has “safety” in its label... ... means the final table name would be
x_snc_safety_safety_issue. He can either label the table as “Issue” or modify the table name to x_snc_safety_issue before it’s created. This shorter version will prove a lot easier
to maintain down the road. Similarly, you can be tempted to build fields
with verbose labels, such as... ... “How many widgets do you require?” This translates into a field named how_many_widgets_do_you_require_... ... because spaces and symbols become underscores in the database. This field label is troublesome for users
because it may not be displayed as expected... ... and developers will have to deal with a long
field name in their scripts. Instead, consider keeping it simple and labeling
the field Widgets to create a field named widgets. Remember, you can always relabel, but you can’t rename. If you want to provide a longer description
for a form field, you can add a hint or clickable link. Alright, you’ve thought about your app enough. It’s time to get started. What do you need in order to start building? The first thing you’ll need is a ServiceNow instance. This is a server running ServiceNow software
that you access with your web browser. You can either use one of your organization’s
developer instances or get a free personal developer instance from developer.servicenow.com. Don’t let the name developer throw you off. This is a great resource! The ServiceNow Developer site has something to offer all skill levels when it comes to solving real business problems using the Now Platform. Here are some things you’ll find there,
completely free of charge! A personal developer instance (or PDI). You can use your own instance running the
supported ServiceNow release of your choice. Developer program members get access to the latest ServiceNow releases before they’re generally available to the public. You can access free learning plans and training,
as well as best practices. You’ll find information about online and in-person events. As part of the developer program, you’re invited to ServiceNow developer events such as CreatorCon at the company’s annual Knowledge Conference... ... as well as virtual and local events like hackathons, hands-on workshops, labs, meetups, and much more. And last but not least, you’ll have access to developer-oriented forums designed to help you build better apps. You can connect with and get guidance from other ServiceNow developers through online forums and in-person meetups. After you’ve got an instance, the final piece is access. You’re going to need either the admin or delegated_developer role granted from an admin account. The delegated_developer role has fewer privileges than the admin role, but it still allows for app development. NOW you’re ready to build your app! Let’s get started in the next video. For more information, see our product documentation,
knowledge base, or podcast. Or ask a question in the ServiceNow Community.