You would have to do a modification to increase the length. Just keep in mind that it’s used and displayed in a lot of places throughout the application incl. mobile apps if you are using those.

Yes, this field is basically a default of what type of PM it is or if it’s a fault that needs acted on.  I always used templates to just default “Repair as Required” in the field on fault reports so folks wouldn’t put the fault description here instead of in the fault field.  It also picks up the Action description from PMs which would be like Action A - Annual PM, Q - Quarterly PM.  So be careful how you use this field and don’t think I’d even consider increasing the character limits.

I’m not sure what this field being used elsewhere in apps has to do with character length… Word wrapping and scrolling isn’t a new concept. 

We have an integration with an Incident Management System (IMS), whereby users can lodge Fault Reports from the Action creation screen in our IMS, whereby the IMS lodges a Fault Report via the API.

As you can see from the screenshot, we have the title of the Action, which is not unreasonably long, mapping to the IFS Directive field which is most appropriate.

It’s needs to be to the point from the overview active work orders table like the title of the book.  If you want details, you have thousands of characters in the Fault Description field.  You don’t need to have the book’s forward in the title.  Also, think about how it looks on mobile devices where a technician would have to scroll or pop open a word wrap to juggle a list of ten jobs he’s trying to keep in mind. 

Funny enough we’ve got about two dozen in-field technicians who use the MWO Maintenance app all day every day who are the main ones who keep asking every week or two about being able to increase the field length (separate/in addition to the integration example I gave above).

We don’t want it to be infinite or to be able to put the whole detail in there, just want it another 20 or so chars longer.

I’ll pass along the bad news to them.

Have them concentrate on giving good fault descriptions.  In the future, machine learning will parse fault description for key words as well as the KPI fields such as symptom and readings to do assisted maintenance that should recommend task templates or start new ones.

I’m not sure what this field being used elsewhere in apps has to do with character length… Word wrapping and scrolling isn’t a new concept. 

We have an integration with an Incident Management System (IMS), whereby users can lodge Fault Reports from the Action creation screen in our IMS, whereby the IMS lodges a Fault Report via the API.

As you can see from the screenshot, we have the title of the Action, which is not unreasonably long, mapping to the IFS Directive field which is most appropriate.

 

I didn’t mean that displaying a longer text would be a problem, but that the field might be defined with a length in different packages and tables that you would have to increase as well e.g. ACTIVE_WORK_ORDER_TAB, HISTORICAL_WORK_ORDER_TAB etc. It’s not impossible, just requires some investigation.