Search Transaction Level Properties

Does anyone else think it would be beneficial to be able to search transaction level properties when your NOT in transaction mode? When doing an advanced search, you can search any property associated with any dimension. However, you cannot search the properties associated with individual transactions unless your in Transaction mode.

A couple of examples of what I’m referring to.

In my Sales database, there’s a property on each transaction indicated if we got a customer’s signature on that order. I can go into Transaction mode, and I can use advanced search to search for where my Signature property = No. Works just fine, and returns a list of appropriate transactions. What I’d like to do is, go to my Warehouse dimension, and get a count of these transactions by warehouse. But in any other mode (Total mode, for example), I loose the ability to search for that Signature property. My only option to work around this would be to make that property a dimension.

Another example would be some additional dates fields in my Sales DB. For instance an “Picked Date” or “Requested Date” that again, are properties at the transaction level. If I’m in Transaction Mode, I can use Advanced search to find orders that fall in a particular date range based on these other dates. But if I want to get a count of these orders by warehouse or by sales rep, I loose the ability to search by this property as soon as I switch to any other mode. Unlike the previous example, created a new dimension in this case wouldn’t really work.

Hopefully this makes sense to others.

I’m assuming there may be performance related issues behind this working the way it does, but I thought it deserved some discussion.

4 Likes

I kind of agree but I think the arguement might be levelled that if you need that sort of report regularly then it should be either a top level Property or Dimension.

Hi @aaron.roma, I tend to agree with @StuartH that if you’re using it, it’s probably best that it’s either a dimension or in the case of dates possibly a new stream. You are correct about the performance implications. If we need to search on transactions that would require the queries to bypass our “speedy” indexing and go down to the “slow” transactions reducing usability.