Basically, yes. There are agreed codes for each condition. If the receiver sees a given code, it expects the condition to correspond to those listed in the published format. However, there are a number of popular formats and variants on each of them. You'll need to provide a means to set deviations from the standard code in case a given panel or location is not fully conformed to the standard.
I'm unfamiliar with that product. If their salesman isn't being helpful, you should look elsewhere or, if you're up to it, write your own. One word of caution though -- central station automation software tends to get pretty involved. It's not for the feint of heart.
Advice is free. Programming assistance isn't. :^)
Other than myself, none of the regular participants here appears to have much background in software development. Even my experience is somewhat limited. I own part of a software firm but I'm not one of the coders. I mostly do help systems, UI design and sales. Between them my partners have over 60 years of SW development.
Every project is either a learning experience or boring. This one's likely to be a little of both. If you start with a good relational platform, develop a modular system that's flexible and easily modified, you'll spend far less time redoing mistakes.
Some firms offer downloadable demos of their software. It might be a good idea for you to obtain several of these and familiarize yourself with what others have done before you even start planning the project. You'll get ideas about useful functionality which you can plan for in your own system.
You might want to build collections of patrol service data, response protocols, local and state authority lists, etc. By linking these to clients based on client location and reported conditions you can avoid a great deal of repetitive (read: error prone) data entry. This will also allow you to quickly make changes to all client accounts within a municipality when the PD of FD decides to change phone numbers or whatever.
The same applies to standardized procedures. Create collections of procedures (e.g., what kind of authority, responsible party, etc., to notify in what order under a given condition). Link to your keyholder and responding authority tables through these rather than directly from each client's account data. This will allow you to rapidly implement changes to all affected customers when some PD decides they want a keyholder or guard service to respond before they dispatch.
There is much more to consider but hopefully this will start you thinking in the right direction.
Recognition of ignorance is a prerequisite to education. :^)
You're most welcome.