Office Hours Q&A
Questions from the live Office Hours session on attribute validation and verification, with answers from Jacob Terry and the CxAlloy support team.
The Basics
Can attributes be done across equipment types?
Yes. Attributes are for all assets, not just equipment, and they can also be on issues, but those are two separate tabs in the project and account settings. You do need to manage equipment attributes and issue attributes separately.
Even though the label may say equipment attributes, it is something of a misnomer. In the settings it is actually asset attributes, and you can apply them to any type of asset. You can attach attributes directly to an equipment type, a system, or any of our location types. In the default asset attributes list a new project starts with, you will find some that are geared toward locations, like floor area and height or width, which are available by default. You may choose to delete or not use those, but the point is attributes are not only for equipment.
How do project level attributes relate to account level attributes? Can you set different limits in a project without affecting other projects that use the same attributes?
They are not connected. Every project is independent. The account list is only used when you make a new project. After the project is made, it is entirely independent and separate from any other project, so all of those limits are project specific.
How do asset attributes for a single project carry over to the account and future projects?
It is essentially independent after the projects are made. But if you make changes in a given project that you find will be useful elsewhere, I would recommend exporting and reimporting that attribute list into the other context, so you can manage these via imports. If you have a bunch of modifications you think will be useful, make those changes at the account level so they apply to new projects going forward, or import them directly into the specific projects where you want to leverage those rule sets.
For more complicated scenarios, like creating large numbers of projects in sync as changes are made to the criteria, or mapping changes from one project into others, there are more customized solutions through our API and through our partner Infinite Built that could assist. So if you have a big portfolio of projects and you like this functionality but want a somewhat complex system for keeping it all in sync, reach out and we can talk about it.
You may also want to duplicate an existing project, which includes the project settings. So if you have a particular set of projects where you want a specific attributes list set up a certain way, but you do not want that for all projects and so do not want to make the changes at the account level, we can set up a demo project with those settings and you can duplicate it for those projects. That is another option.
Which permission setting allows access to attributes?
That is the Manage permission for Settings. There is one permission to view and manage the settings section, so all of the project settings are lumped under the same permission right now. The settings capability shown in the demo requires the Manage permission for Settings, which is the Settings row, Manage.
Setting Up Validation
Can validation ranges be adjusted for different pieces of equipment, or is the range set for the attribute across the board?
It is set for the attribute across the board. You cannot have different ranges for each asset on the same attribute. To do that, you would create a different attribute for each case, targeted at a group of equipment, for example rooftop units versus air handlers versus a subset of air handlers, using separate attributes with differentiating names to keep it clear.
One approach is to make a separate attribute for each expected range, grouped by what you expect for those subsets of equipment. That will grow your attribute list, so you would have a lot of near duplicate attributes by the end of the project. You can merge them two ways. Directly in the spreadsheet as you go along, just for checking progress, and in the actual product settings, where once all those values have been collected and verified you can merge the attributes together so it is a single column. So you do not have to worry about keeping those separate instances after you have gathered the values.
One added thought on that. If you have targeted the attributes at groups of equipment and named them appropriately, merging them back may not be a necessary extra layer at all. It can work out fine as is.
We also have some ideas we are exploring, with no timeline committed yet, to make the validation criteria dynamic based on other values defined on that equipment. It is very common to have specified and submitted values recorded separately, and those could then be used as the minimum or maximum constraint for an installed value, for example. We see that as a fruitful area, and we are very open to suggestions on it, because the main limitation today is that validation criteria is project wide for a given attribute.
Is there a way to set date restrictions relative to the day the attribute is entered, for example the date selected can only be within three days of the current date?
Not right now, but that is on our shortlist of enhancements, to make a relative date based rule. The reason we did not implement it initially is that we have to pick our scope, and a relative rule introduces a variable where the validity of the value changes as time passes. The logic has to be a little different, because validity is really enforced at data entry time.
It also brings up complications. If the rule is that the date must be within three days of today, you enter a value for tomorrow and it is valid. If you go back a week later and make some innocuous edit, and we were to reevaluate at the point of editing, it would then be invalid because it is outside the three day range. So do we validate only on creation and not on editing? Those are questions we will work through. We decided to hold off on the relative date implementation for now, but we do plan to put it in place, and it is on our shortlist.
Is there a way to have a blank field included in the unit options?
Not really, and units are also not mandatory. You cannot mix it. If you have defined an attribute as a number with units, then when someone enters the value they must pick a unit. If you set it up without units, it is just a number field and there is no unit to pick. But you cannot have units defined and then have one of the units be blank.
What you can do, if you want to allow a mix of unit based and unit less values, is add a unit called something like unknown, or NA, or unitless value. That is what people would pick when the unit is unknown or irrelevant. The application will require them to pick a unit, so if you want to allow for the unit being essentially irrelevant, you would put in an entry like that for them to select.
Existing Data, Flags, and Finding Things
Does this change the way asset attributes are imported?
Yes and no. Your imports are essentially the same, but there is an extra step now on the back end where values are validated based on each attribute’s settings. The import itself is not different for equipment or your other asset sections, but you do want to be aware of the rules for those attributes when importing.
The import will alert you if there are attribute values you are trying to import that do not meet the criteria. That is now a step in the import that tells you those values cannot be imported because they do not meet the criteria, and shows them to you. So we do enforce those rules on import, and we give you all the information about any that fell outside the validation requirements.
Can you search for flagged attributes? Will there be notifications for flagged attributes?
Right now, what we have for flagged attributes is the filtering capability shown at the end of the demo. We do plan to add a dedicated report or view that shows all of the invalid flagged attributes in one list, to make it easy to go through and take action. That is planned for the coming months as a follow on to this initial release.
We do not have any formal plans yet for notifications around flagged values, but it is certainly something we are open to considering. There is quite a bit we could potentially do to make these capabilities more valuable, but the first thing we are looking to do is the dedicated report that consolidates all invalid values into one review list.
Do you have plans for push notifications to select project team members for issue attribute or equipment attribute flags?
Not right now. We are working toward an in app notification system that we expect sometime in 2027. That does open up opportunities for us to be a little bolder about things that right now do not feel like they merit an email, since we already send lots of emails, but that would be good to be notified about. There is opportunity there, but there is nothing currently planned on that front.
Is there functionality for filtering on attributes within the CxAlloy interface?
Yes, you can search on attributes, which is probably the best way to filter. On the list views, the search bar has a major fields drop down on the left. Major fields searches the items themselves, like the name, and on issues also the description, depending on the list. If you click that drop down, on the equipment and issues lists you can switch it to attributes and search the attribute values instead. That is the best way to filter on attributes within the web application.
Verification
Do imported attributes count as a source for asset verification?
No, they do not. It is simple, but it can get mixed up. The current value of the attribute is whatever it is. It might have been set by a checklist, where the value recorded in the checklist automatically set the attribute value too, but at that point those are two distinct entries.
What we are doing is always comparing the current value of the attribute, whatever it is and which you can manually edit directly without touching a checklist or test, against the values that exist across all checklist and test lines that ask for it. So the start of the comparison is the current value of that attribute, and we compare it against the values recorded in checklists and tests. An import sets the current value, but it is not counted as one of the independent recordings being compared.
If verification is enabled, does that override the auto fill for attribute values in checklists and tests? If the value is prefilled, that limits the usefulness of verification.
Good question. Right now, with verification turned on, it does not stop the confirm prompt from showing in a checklist or test. The idea you are getting at is that if verification is on, maybe it is too easy to just confirm the prefilled value without really taking the time to check it manually. It is an interesting idea and good feedback, something we can consider and take back to look into.
One thing to mention on the validation side. If you have a preexisting value that is invalid, we will not show the confirm prompt in that case, because it is not a value the system should accept. You can have invalid values for a variety of reasons, for example because you already had values and then put a rule in place, or an allow and flag scenario. In those cases we do not show the confirm prompt, because the existing value is not right as far as the system understands, so the person has to manually enter a valid one.
Two tanks were assigned the same serial number under two different checklists. Is there a way to verify there are no duplicated serial numbers?
We do not have any dedicated feature to flag that particular scenario. The best solution right now is to export the list and run a duplication check in your spreadsheet application. There is nothing directly in CxAlloy that flags those.
It is a good point, though, and interesting. Serial number is one of the few cases where you would want a value to be totally unique, but it is not the only one. Some customers record a secondary system ID as a custom attribute, which is another case where you would not want to reuse an ID value across multiple pieces of equipment. One possibility we could look at is making it a setting on the attribute itself to not allow duplicate existing values, or to highlight them. We do not have anything for it today, but it is something we will take back.
Working with Other Features
How do issue attributes differ from issue presets, and how do you combine the two?
Issue presets can include issue attributes. They are two separate things in the project settings, but you can add attributes to issue presets, and when you apply a preset it automatically populates the form with whatever attributes are included.
For example, a preset can include a root cause attribute left blank, which is not normally possible when creating an actual issue, but for a preset you can say you want the attribute added without prefilling a value, so the person has to set it. You can also include an attribute like cost impact with a starting value. When you add an issue and select that preset, it drops those attributes in automatically. If a value is preset, it prefills. If not, it is left blank. And when you save the actual issue, any required attribute like root cause must be given a value.
It is also helpful to know that when you are creating checklists, tests, and templates, their individual lines have a setting to automatically prompt issue creation when a line fails, and you can select an issue preset to be automatically applied when that issue is prompted. So if you anticipate specific types of issues for particular lines, you can save overhead by setting that on the templates.
How do I give rights to contractors who already have access to CxAlloy to use the OCR function for populating attributes on checklists?
If they have the Respond capability, they should be able to use the label scanning ability. If someone can respond to and fill out a checklist, then as part of that they should be able to pull values from the scan, the OCR, where you bring up the camera, take a photo of the nameplate, and select the text to drop in as the value. That should be tied to the Respond permission. If that is not what you are seeing, email us at support@cxalloy.com and we will dig in to figure out what is going on.
Is there a way to validate attributes over the API? We use tooling for seeding and creation of assets and attributes over the API, and we verify our project against our seeding databases.
We do plan to update the API with full support for this validation. Right now it is not in there. To avoid breaking any existing scripts and to ensure backward compatibility, the API continues to allow any value to be sent up for an attribute even if it falls afoul of the validation rules you have put in place. It will be flagged as invalid, but we will allow it through so we do not start rejecting script based or API based workflows.
As part of this release, you will get that invalid data back, so when the attribute data is returned, we will tell you whether it has the invalid flag on it. That is coming through the API now. We will also be updating the API with the ability to control the attribute validation and verification rules themselves, the actual configuration of the attributes in the settings area shown in the demo. That is a little way out, but it is being worked on.