Watchlists serve as an alert system. In simple terms, this feature acts like a query running continuously in the background in JDE to let you know when certain conditions are met. In JDE, Watchlists provide a dashboard view that gives you a proactive way to look at potential issues and resolve them.
Watchlist Use Cases in JDE
Example 1: When you create a journal entry for Accounting purposes, it adds a new record in your transaction table and updates the balance in the balance table. You could set up a Watchlist to let you know if the balances are out of sync (if the sum of all the transactions doesn’t equal your account balance).
Example 2: In Real Estate, you might use a Watchlist to identify units that are missing an asset. On the Watchlist screen, you can see the status of how many records violate that query. From there, you can go directly into the JDE application that lets you see the prefiltered list of items that match those conditions and the query used to find them.
Watchlists as an Orchestrator Component
When using a Watchlist as an Orchestrator component, you simply select new and choose the Watchlist that you want. It gives you basic information about the watchlist, such as the maximum number of records, the warning threshold (yellow), and the critical threshold (red). All these are available as outputs to pass to a future step. You can also choose additional outputs based on fields from the Watchlist such as query name, form ID, or last run time.
How Useful Is This Component? While many of our clients use Watchlists, not many use this component in their orchestrations. The people who need to see what is on a Watchlist will typically be in JDE and simply go look at their Watchlist menu or UX One Pages.
Theoretically, you might set up a Watchlist as part of an orchestration if you needed to pull a Watchlist with critical status and send it to a third party via a notification. Or, if a Watchlist reaches a certain threshold, you might take the result and its associated application form and send both to a future form request to interrogate that data and automate corrective action.
Full disclosure: In all our years of working with Orchestrator, our ACBM team has never used this component. If you have, please reach out and tell us your use case. We would love to feature it on our blog!
Next up, we’ll look at a much more useful component: Custom Requests.