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, we don't document the fact that our Active Directory Sync service doesn't run on a Mac.)

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.

The loginHub in general is documented for the environments it does handle, not the environments it doesn't. There are literally millions of ways to setup networks, the LoginHub relies on very specific conditions, and while the number of environments and flexibility of the LoginHub increases with each release, it cannot, by its very nature work outside of several of the millions of options.

This is, by its very nature, the biggest design limitation of the LoginHub.

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'/'Not support' mean you won't help me with problems?

No, what it means is if a problem is related to a setup that isn't in the set that we support or 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.

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/was a design limitation' or 'that's not a supported configuration'. 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.' 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.

Once we understand your configuration, we do try to add it to our supported configurations.

Some limitations that may or may not be obvious

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.

It happens 'now', not a year ago

When you do a DataHub import, any triggers that get triggered happen 'now' where 'now' is the instant that the data is added to the database. This means that some things may look a little funny when you are bringing in historical data that is more than a day or so old.

A common one:

If you have an issued date but not a responded date, the MC triggers (not DataHub) will change the issued date to 'now' so that the history records line up. But if you have both a responded date and an issued date, the MC triggers won't change the issued date. As a result, either your data, or the way you set up the DataHub connector should bear this in mind and decide what you want done - again bearing in mind if you use an issued date of a year ago, being transactionally, the side effects (the effects of the triggers) will be recorded as 'now' not a year ago.

Once your system is set up, if you are importing data that is 'being created' on another system - using the example above, perhaps you have a separate CRM that is used to generate some or all of your WOs, you should look at having them brought it at least once a day, maybe twice or more often, so that other records line up better with the dates of the work order issued date.

Deprecated (Applied up to version 8.3): You must use IE

To setup the DataHub, we use Silverlight, and Silverlight only runs in IE.

DataHub does not run in a transaction

A transaction means that if something crashes, the database will roll back to the state it was before. The problem with bulk loaders like DataHub is that this can mean it takes hours to run (causing timeouts) and can consume Gigabytes of memory and Hard drive space as SQL server preserves enough information to 'roll back' to the previous state.

So if there is a network crash, computer crash etc.., during the import, it may be necessary to do manual fixes and/or restore from a backup. While this is true, in real life, it almost never happens.

To minimize problems, we do a first pass to validate the data before starting to save.

UI 'manual import' works best for small volume 'test' data sets

The ui is designed to be optimized for low volume use/imports. It has two principle purposes:

1. To test your DataHub connector,
2. To do 'one time' imports, without having to set up an Event & Action to read it in.

E&A for DataHub tell when there is an error, but you need to use the 'manual import' to get the detailed error.

If you set up an Event and Action for DataHub to import on a regular basis, the assumption is that you have tested it. Since there is no user watching the automated process, you can send yourself an error notification when it fails, and the history will show it failed. But the complexity of errors is such that the history can't easily show you WHY it failed, and so you go in and run it manually to get the details on the problems.

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

Let [email protected] know, we'll look at adding it to the next version of this document. Updates of this nature are usually live within days of us becoming aware of them.