Global information services

Posted June 9, 2020 by Clark Wilkins

This is a repost of content we published on the stockd blog because the process is identical.

In late March, we started a research project to explore the concept of sharing a subset of information between multiple Simplexable services. The idea was to explore finding a way to share “assets” such as customer information between our services, so our clients who run more than one platform could define a customer, for example, once, and share the account between stockd and servicd.

Along the way, we experimented with a lot of techniques, such as our suboptimal experiences with AWS Serverless technologies. It was a long and, at times, very difficult transition, but we're happy to announce that it's completed. We'd like to share a bit of what we've created, and why it matters.

global customer interface

In the screenshot above, we are looking at a customer account from the stockd platform, but the information is being pulled from an external service. Not only is it external, but every bit of the logic, storage, and every other aspect of this screen was redesigned so we can use it on stockd, servicd, accountd, and any other service we may decide to integrate in the future. It's just a matter of a few definitions and changes, and this customer suddenly becomes available without any need for the client to take any action beyond clicking one of the platform accessibility checkboxes.

what's the use case?

Ok, consider this real-world example by starting with stockd and how it uses customers. In this platform, every sales quote requires a client account whether we've sold to them or not. This is critical to identifying who's being quoted — so we can not only track the quote, but all of our interaction with the client. This is local contextual reference information that's relevant internal to stockd.

Now consider the same customer information within servicd where we tie the customer account to service jobs. In this case, the customer is not a servicd client, so we don't even show them on the list. (This is why the servicd checkbox is not set.)

However, this client has placed one or more orders which we've billed in our accountd platform. There, we link customer accounts to invoices, statements, and payments — local contextual reference information that's only relevant internal to accountd.

There are times when we are quoting clients that never buy anything :-(, so they are only enabled in stockd. We have clients that only purchase consulting or platform services from us, so they are only in servicd. Each situation is different, but you can redefine the scope of a client with a single checkbox, and everything you know about that client becomes accessible.

extending the concept to policy

Now consider the idea of defining a default communications policy. In the case of the client below, we have two contacts linked to the customer. One is the Accounting department, and the other is Sales. In the context of stockd where we do sales quotes and orders, our primary audience is obviously Sales. On the other hand, when we're sending invoices and statements, Accounting is our primary audience. This is an implicit information policy, but the question that Simplexable is addressing is “how do we make this clear to our staff?”

setting email policy

The new API interfaces make this simple. We defined a default settings which says:

This setup gets deployed automatically, so any user sending an email to this client gets the default address setup. This is what we call a defined email policy.

where else is this useful?

At the time of this blog post, we've extended these ideas to users and vendors. In each case, we define a “single source of truth” and extend access for the user or vendor to the relevant information platforms. The vast majority of our client's data is not handled this way, because it's only used in one platform/company, so we have nothing to gain by rewriting a large and well-performing application. However, the benefits of global information services for users, customers, and vendors has more than justified the immense amount of work that went into this project.

prev: On-demand data exporting