Introduction

Through the years we have provided in our standard documentation many known product limits. Others are not documented because they simply exceed the design so generally we don't even think about them. (For example, if you buy our wo technician, we do not document the fact that it doesn't let you edit zones or holidays.)

We understand that many people do not read the documentation, and indeed, this is largely because we try very hard to make the product so easy to use that documentation is seldom needed, but it doesn't change the fact that, like any software, there are limitations, things it doesn't handle.

Further, with each release of the product, the restrictions, the things it cannot do, get generally smaller and we try to be more and more flexible.

In addition, we are well aware that many customers consider the product to work well in their environment even though we document that it doesn't work and/or isn't supported.

Often this is because they have found a way around some of the specific limitation(s) and/or they have developed a 'hack' that works with that current version of the software.

We have pulled together in this document a discussion of several of the more common limits that customers sometimes ignore. None of these are new – they've all been in our publicly available documentation for years, but what is new is pulling them together into this one white paper.

Are we documenting EVERY limit? Absolutely not! That would not be practical. And in any event, we focus on what we CAN do not what we can't.

My Hack or work-a-round worked the last release: you have a bug my hack doesn't work anymore.

Sorry, that's not a bug. We do not support that, and any assistance will be billed at normal rates.

Does 'not supported' mean that if I do it you won't help me with problems?

No, what it means is if a problem is related to exceeding limits or doing things that are not supported we simply bill those things by the hour and we will not likely try to fix them as quickly as we do bugs, if ever. But things that are not related are still supported by our normal terms. It also may mean that when we offer a solution, it may be an extra cost product.

Are we listing all the problems of ignoring the limitations below?

No. We don't test these often if ever so we don't know all the issues.

Can I tell you about a 'bug' I find when I ignore the limitations?

First of all – this is commonly how people say it to us, but don't be surprised if we say 'That is not a bug, that is a design limitation'. We, and most people, define a bug as 'Something that it is designed to do and doesn't'. But we understand many people define a bug as 'something I don't personally like'. So we might say 'that's not a bug'…

But then we DO listen, and we consider when and how we can have our software not have that 'issue' or more important - how we can help you get what you need to succeed at your job. If you want it changed sooner than we decide (or if we decide we aren't interested in 'fixing' it) then you can talk to us about having a customer sponsored feature – a feature you pay in part or in whole for.

Some limitations that may or may not be obvious to you

We picked these because customers have told us in the past that they are ignoring the documented limitation and/or are surprised by the limitation.

One work order, One assignee at a time

We do not support two users updating the same work order at the same time. This also means that we don't support one work order being assigned to two or more people at the same time.

Having said that:

We have done a lot to make this work reasonably, and as we are alerted of 'issues' this is one that we do put a lot of work into improving. There are still some known problems and so we do not support this. But if you want to do it, here are some tips that users have come up with:

• Sync changes frequently
• Set up 'policies' so no one person does something that conflicts
  • don't let one person close the wo when someone else still has work to do, don't let two people 'edit' the notes.
  • Don't let 2 people edit the same address. If the person who sync's first changes the city and street address, and the second person who sync's changes the postal/zip code and street address – you will possibly have a mess (you will get the 1st person's city change and all the 2nd person's changes). Last change wins.
• If someone deletes the wo you are working on, you will have sync problems that will require a support person to help you fix

We DO support these:

• With 8.0 we added the concept that you can 'add' to notes. The order won't be the order they were entered – it will be in the order they were sync'd. But, do NOT rely on this! A future release might be become better at putting them in the entry order.
• When you sync, as of version 8.3, we look for changes that others have made and we bring them to your device. (Prior to 8.3 we had a feature 'release wo's', but with 8.3, we now have this better way and so we removed the 'release wo's' feature.)

It is our intention that with each version we will look at ways of supporting this more and more, and someday we might move this to the 'supported' list.

One user, two devices and/or two browsers

This is largely the same as the issue above. Again we know many people successfully do this. But the same problems exist as above.

Having said that:

If you sync on the device you just made changes, then sync on the device you switch to, or if you work on different things on both devices, you have a better chance of having a good experience.

One browser, multiple tabs

This is an interesting way of running that some users do, having several copies of MCe open in different tabs.

There are several, mostly 'minor irritating', issues with this.

There are a handful of 'data can be lost' issues with this, in particular with respect of the sync. 2026.02 update: At this time we are not aware of any data lost issues with this. There are some issues with items disappearing temporarily from the lists, but they show back up in the next refetch.

Having said that:

Most users who do this report to us that they have never run into a problem. So, while we know how to easily cause problems and therefore we do not support this, apparently most users who ignore this limitation do so in a way that doesn't cause problems.

Suggestion: If you want to ignore this, use one tab for changes and the other tabs for just reading info.

Suggestion: Never open the same thing (such as the same WO) in 2 windows. 2024.10 We don't think this is a problem anymore.

It is really powerful when doing UIConfig - make changes in one tab, review the results in another

Each device, only one user

Fortunately, given the cost of devices these days, and plans that come with 'free' devices, we run into very few customers that try put more than one user on the same device. But if you are or you are thinking about it … then please read the following.

Our software is focused on giving the best possible online AND OFFLINE experience.

On cell phones and some tablets, the biggest issue is running out of memory and storage available to us by the browser.

Having said that:

As of version 12,.1.4 an issue with LoginHub and users not using the MCe login features but always going back to the identity provider has been resolved.

As of version 12.0 this is actually working pretty well. A few of the 'remember where you are' features aren't as friendly with multiple users - but you probably don't expect them there anyway. The key thing to make it work is make sure all users on the device have access to the same database. This is only an issue for the small percentage that have users with access to multiple databases.

Hospitals - with a 'floor' computer that is always logged in to a generic user is the most common use case for one device, multiple users.

Due to memory and storage, this works best with Windows, Mac and Linux browsers that tend to have lots of available storage and memory.

We have many other issues we have to solve (we know how, it is just a matter of time and money) and as of May 2018 we only know of two customers that even want to do this, and of those two, only one is using a device (iPad) that won't let them easily do it. (The other is on a windows machine and they figured a way to get around the limit without doing a retire device every time they log out. Their hack will only work on Windows the other devices like Android and iOS don't have enough flexibility to use this hack.)

If you only want two or three users and you are using a 'full blown' computer that 'has' to be left logged on to the same user, you can have 2 or 3 browsers, and each user can use 'their' browser. But since there are only a few browsers to realistically chose from, this doesn't work if you want dozens of people to use the same device.

Reasonable number of WO's and Tasks and Assets etc..,

Each version of MCe gets better at handling more and more data. MCe 8.3 was a huge step forward in this.

There are still practical limits, but few customers run into them anymore (circa MCe 11.x).

With version 1.0 we limited the system testing to 10 wo's with a max of 20 tasks per wo.

Now with 8.3 we have users successfully having 100 assigned wo's and 5,000 tasks per wo. (This last, lots of tasks, requires you own our advanced procedure creator module that allows multiple header LEVELS and then use them in a reasonable way. If you don't then the limit is more reasonably 100 if you have no headers and 1000 if you have enough well-defined headers.

Some of the limits are based on the UI. Again, in 5.3, there was no option for hierarchical tasks and the practical limit was a couple hundred (though we had users working with 800+), as of 6.9 you had more and more flexibility with task headers that made larger numbers reasonable.

8.3 brought dynamic scrolling, instead of loading a thousand rows of something, which made the device very slow (especially iOS devices), we now only keep about 20 in memory. I you have have than about 50, you should be filtering to limit the choices.

8.3 brought 'online' accessibility, this gave access to a lot more data, some cached on your device, some requested as needed.

The limits vary based on your environment:

Device: Windows can handle the most amount of data, Android next, iOS the least (iOS has hard limits that are extremely low compared to Android, and Windows has no limits other than disk space.) These limits can change from os version to os version, especially on iOS.

Browser: Safari has the greatest restrictions on amount of data. All others your limits seem to be based on your hardware.

Network speed: The faster your network speed the more data you can realistically have on your device.

Network reliability: The fewer 'lost packets' the more data you can realistically sync and the better your online experience. This one is important to note since many people use MCe strictly for its offline capability and many of these have poor connectivity with lots of dropouts. We test a LOT with very bad internet connections, but whenever you can, when doing a big sync or upgrade especially, try to use a reliable fast connection – your experience will be much better.

Device memory: The more memory, generally the more data and the faster your experience will be.

But note, on iOS, even if you have lots of memory, iOS puts limits as to how much data you can have. (Chrome and Edge on Android and Windows do not.) This is not normally a problem, but if you have lots of images/thumbnails being downloaded or you try to run connected to multiple databases, you may need to have your administrator restrict your queries to lower the amount of offline data.

Device Speed: The more data you have, the slower everything will run. In most cases this is not noticeable, but in some it is. We don't specify what those 'limits' are because devices keep changing in speed and anything we say today would be outdated in a month. Instead, we recommend you test your devices before you buy a lot of them. There is, unfortunately, one constant, I hate to always be 'down' on Apple, almost all our senior people have and regularly user at least one or two iOS devices and/or a Mac (the author of this document has an iPhone, iPad and a Mac) – but these are the facts: At any price point, Apple will be much slower than Android or Windows.

It Isn't MC, we don't have every feature or field

We do not support every feature or field of MC, Maximo, SAP, Hexagon or MaintainX. Our WO Technician has features that our customers and we believe are key for WO Technicians. Yes, you may think another feature is 'critical'. We continue to implement features, but some will never be in the WO Technician. We don't document all the features that are different, and new features in MC may or may not be included in MCe.

Having said that:

We listen carefully to customers and while we don't add every feature every customer asks for, we have added most, and we continue to listen and put requests into our future development plans.

It isn't MC/Maximo/SAP/Hexagon/MaintainX, we don't have the exact same way to do everything.

For example Maximo & SAP don't have an asset tree, and MaintainX's asset tree is limited to mom and pop service centers with only 3 levels of depth.

Most things we do are very similar in the way, after all, it just makes sense. But we heavily support off line, and many of our users use cell phones and tablets, and all of that means that the way we do things are often a little different. We do not consider these differences bugs. In addition, we are strongly offline, and our caching of data gives some huge benefits even when you are online. We are committed to being compatible, but we are not committed to being 'the same'.

In general, we take the attitude that users that use MCe are generally unlikely to be the same users that use MC, and hence, the little differences affect very few people.

Note that it is our opinion that MC Express is even more different from MC than MCe is.

It isn't MC Express, we don't have the exact same way to do everything.

MC Express has its UI optimized only for cell phones, we have ours, optimized UI for both mobile and desktop.

In addition, we are strongly offline, and our caching of data gives some huge benefits even when you are online. We are committed to being compatible, but we are not committed to being 'the same'.

We do not consider these differences bugs.

In general, we take the attitude that users that use MCe are generally unlikely to be the same users that use MC , and hence, the little differences affect very few people.

Note that it is our opinion that MC Express is even more different from MC than MCe is. Also MC Express has features that are not in either MC or MCe.

Scrolling through 1,000 rows isn't practical

Even scrolling through a few hundred probably isn't. So … we give tools like different queries and filters to limit the number of rows you are working with. If you insist on having 1,000's of rows and scrolling through them, it will work, but we consider it impractical. Use our hierarchical tasks if lots of tasks. Use search and filters in most other places, or build queries for a permanent way.

For phones, we only support current and previous Android version and current and previous iOS version.

Though it does tend to work back further than that with most upgrades.

As you have more and more data offline, you do need faster devices to achieve the best experience. We recommend you test devices with the amount of data you plan to have on them to see if you are happy with the performance – especially if you are going to buy a bunch of them. But moving to specific categories:

We used to support Windows phones, but they are dead. We have no users currently using them (2018) and they are almost impossible to buy new. If you find a supply, we recommend that you not buy them since we have stopped supporting them, they still work last we heard, but we aren't testing on them anymore.

We used to support a few Blackberry phones, but they are also gone.

Apple sells 'older' (so still 'current') devices until they are several years old. Most years the speed improvements aren't very significant so the major factor usually is: Does the phone upgrade to the most recent Safari?

Android phones we try to support as long as possible, for most phones – the major question is: do they run the most current Chrome? Most years the speed improvements are modest. (Interesting note: 2018 saw one of the most dramatic speed improvements, phones based on the snapdragon 845 run approximately twice as fast as the 2017 snapdragon 835s even though on paper they should only run 25% faster. Our best guess is that this is due to the older ones overheating after a few seconds or minute of running fast and 'clocking down' – running slower – than the specs suggest, while the 845 seems to be able run much longer without overheating)

For tablets we only support modern Android, Full windows, iPad

We don't support Linux (though it will probably work), we don't support Crippled (I know that is a derogatory way of describing them) Windows. We support 'real' windows. We don't support the kindles or the many others. For windows devices, if you can load a full Google Chrome then your device is good. If you are running on one of the restricted versions like the short lived Windows RT or Windows S, Microsoft restricts features heavily and so we are unable to run on them.

For other machines, we only support Windows and Mac

We don't test or support Linux or any of the 100's of other almost never heard of desktops. We don't support Raspberry PI or Ardrino or any other such, we don't support mainframe computers or anything else not listed above. If you really want to try, see if there is a modern Chrome browser that will run on them.

Update 2025: We do test periodically on Linux - typically Ubuntu, and with Chrome browser it seems to work fine, but we don't officially support any of the 100's of Linux's.

We only officially run on Windows, Android, Mac and iOS

We are admittedly surprised that no one has asked us to run on Linux. For several years FireFox was the major browser and it went downhill terribly when it's founder 'left' the company.

If a company were to buy a large enough number of copies we would consider adding other operating systems to our test bay, and if successful for long enough, we would consider officially supporting them.

So, we don't know (and mostly assume we don't) run on OS's including eComStation, Haiku, MS-DOS, PC-DOS or any other *-DOS OSs, PalmOS (but we used to! And we supported it until about 2016 when our last customer with PalmOS had their last Palm clone die), WindowsPhone (but we used to, and we supported it until our last customer with it had their last device with this OS die.) ReactOS (last we checked, Chrome didn't run on it), Syllable, any of the UNIX or UNIX clones or UNIX look-a-likes including Linux other than Android and MAC-OS and any BSD based, Solaris/SunOS

Having said that

If you have one and it runs up to date versions of Chrome, you might find it works for you. But we won't be testing on it or providing 'free' bug fixes.

We have a separate document that talks about browsers we support

But essentially, we support the most recent Chrome, Edge and Safari. Some features aren't available in Safari – but that is because Safari doesn't support them or doesn't fully support them (yet?), once Safari does, we will too.

We support the most recent and previous version 'at time of shipping'. We try very hard when a new version comes out to fix any bugs that causes, but with newer versions of the software, we make no attempt to work with outdated versions.

We dropped support for IE around 2017, it is just too old – too many things don't work in it – on purpose, Microsoft doesn't want you to run modern software on it, they want you to stop using IE.

Good news for iOS/Safari users: We do more than 50% of our testing on iOS devices (iPhones and iPads) and we plan to continue that until when/if iOS is no longer the buggiest platform. So we fortunately catch most iOS specific bugs and work around them before you do.

Note: The 'Edge on iOS' and 'Chrome on iOS' are NOT browsers we support. They are 'skins' on top of Safari.

More as a summary:

We don't support Internet Explorer (IE)

Microsoft stopped development of IE years ago. They claim it is designed for 'legacy' web apps. MCe uses so many new features in newer browsers that it would be highly impractical to support IE. If you have a Windows device that is older, you should use Google Chrome on that device instead of IE.

We don't support old versions of Chrome, Safari, Edge

All of these browsers have free upgrades. We recommend you not be more than a month behind.

We don't 'yet' support newer versions

Obviously it is impossible to guarantee that our software will run on versions of browsers that didn't exist at the time we shipped. We do test on pre-release browsers (like Chrome's Canary) so that we are very likely to run on upcoming browsers, and that means we almost always have our software to you to work on newer browsers (if you have paid up SMA and you allow us/ask us to keep it up to date.) If you run into a problem after a browser upgrade, chances are we have a fix we can install for you. (Don't upgrade to an iOS x.0 - we have the worst luck with those, we assume that they are rushed to meet arbitrary deadlines, wait for the .1 bug fix - those are usually, only 1 exception, more reliable.

HTTP:

We stopped officially supporting HTTP around 2016. This is in part for security, and in part because browsers are actively taking AWAY features when you run in HTTP and all new features of browsers require HTTPS. Back in 2016 this was a fairly radical decision, but in 2018 it is clearly the 'industry standard'. If you chose to try to run in HTTP – we have done everything we can to run as best we can in HTTP, but the number of features the browsers are taking away means less and less will work and eventually nothing will.

Sadly for those that want to stay in HTTP, there is really only one option: Stop upgrading your browsers – use the early 2016 versions, and stick with MC 7 and MCe 5.3 until you can join the HTTPS world.

Closing the browser (or last tab for web site in browser) logs me out.

Don't rely on this. Use the proper logout functionality. While it is true that, as of 2018.04, in most of the browsers we support in most devices we support, concurrent licenses are released and you are 'logged out' when you close them, this behavior is not guaranteed and may change because of even minor changes we or the browser or the Operating system (Windows, Android, iOS, MAC). So … use the tools we provide.

When I hit the browser back button …

Don't! Well, you can if you want, but the behavior is different in different versions of MCe. Like most web apps, we don't support the browser back button, use the navigation buttons we have. The equivalent of the back button is usually in the upper left corner of the page – scroll up.

We don't run in privacy/incognito mode

This mode purposely is set up by the browsers to limit all sorts of things. For example – they don't let us cache data. So we don't and we never will run in privacy/incognito mode/window (different browsers have different names for this.)

While our software is vastly multi-lingual our manuals/whitepapers are not

In a survey of users, very few ever read, and those that do only read small amounts. The cost of translating and maintaining manuals in more than one language would be extreme, if a company was interested in sponsoring a language (costs and perhaps talent), we would work with them to do so.

Other limitations – practical or 'breaking' you have run into and think should be in this document?

Let your support person know, preferably by email, and we'll look at adding it to the next version of this document.