Log Finder: every forgotten log line and API call in a OneStream app, in one search
A single OneStream dashboard that finds leftover logging in business rules and lists every rule that uses a given API call, so clean-up and upgrade checks take one search instead of opening rules by hand.
Quick facts
- Industry
- OneStream admin tooling
- Role
- Designer and developer
- Timeline
- 2026
- Team
- Solo build
- Status
- Working tool, delivered as one importable dashboard
- Impact
- Two questions that used to mean opening rules one at a time are answered in one click each: which rules still log, and which rules use a given API call.
- OneStream
- VB.NET
- Dashboards
- Business Rules
On this page
Overview
Over the life of a OneStream application, developers leave logging in business rules while they troubleshoot. Much of it is never removed. Extra logging bloats the error log and can slow calculations, and it is easy to miss when preparing for go-live.
Log Finder is a single dashboard that reads the application's own rules and answers two questions. Which rules still write log messages? And which rules use a particular API call? Results appear in grids, and each run also saves a match log.
The Problem
- Leftover debug logging. Troubleshooting adds log lines that stay behind and quietly make the error log noisy and calculations slower.
- No easy way to search all rules. An application has many business rules plus member formulas, and checking them means opening each one.
- Upgrades and deprecations need impact analysis. When a OneStream release changes or retires an API call, the first question is which rules use it. Without a search, the answer is a guess.
How It Works
Open Logs List
One button lists every rule that still contains an active logging call. A rule whose logging has been commented out is not listed, so the list shows only what is really still running. The result is a short clean-up list to work through before go-live or an upgrade.
API Finder
A search box takes any API call. A common example is already filled in as the default, the utility that returns the file-share folder. Press search and the grid lists every business rule that uses that call on an active line. This turns an upgrade or deprecation notice into a defined list of rules to review.
How It Reads the Code
- Business rules: every rule in the application is checked, except encrypted ones, which cannot be read and are skipped.
- Member formulas: these are scanned too, for the logging search, because logging hides there as well.
- Commented lines are ignored. Only active code counts, which keeps false alarms out of the results.
- A match log is saved on each run, so the findings can be kept and shared.
Packaged as One Dashboard
The whole tool is a single importable dashboard with its supporting rules. There is no install and nothing to set up beyond the import.
Results
| Metric | Before | After | Change |
|---|---|---|---|
| Finding rules that still log | Open every rule by hand | One click, results in a grid | 1 click |
| Finding rules that use an API call | Open every rule by hand | Type the call, one search | 1 search |
| Commented-out code | Mixed in with real hits | Ignored | fewer false alarms |
| Record of the findings | None | Match log saved each run | kept |
Soft outcomes:
- Cleaner go-lives. Leftover logging can be removed before it reaches production.
- Upgrade planning with a real list. Teams know which rules to review when an API changes.
- Easy to hand over. One import and any administrator can run it.
Learnings
What worked. Treating commented-out lines as not-there. Results stay short and trustworthy, so people actually act on them.
What I'd do differently. Encrypted rules are skipped because they cannot be read. A visible count of how many were skipped would make that gap clear to whoever reads the results.
Skill developed. Turning an admin chore into a search. Many OneStream clean-up jobs are really questions about what the code contains, and a small dashboard can answer them.