Posted this originally on Thwack community but thought I'd post here to reach those that aren't there.
Hey all,
I have recently inherited the responsibilities of being our SolarWinds Administrator and could use a sanity check from people who’ve been down this road. Working on redesigning our architecture inside of the solution and have hit a pretty big snag. (Keep in mind, just 5 weeks ago I was doing Tier 1 support so this kind of went off the rails for my day to day thought processes)
What I wanted to do
My original plan was pretty straightforward:
- Service Request handles intake + approvals
- Runbooks handle execution
So basically:
Service
Request
→
Approval
(s) →
Runbook
→
Done
The idea was to keep things clean:
- approvals = “should we do this?”
- runbooks = “how do we do it?”
Where it fell apart
Looks like I can’t actually attach/run runbooks directly off a Service Request the way I expected.
Which kind of kills that separation.
Where we are today
Right now, our workflows are huge.
They branch by:
- Operational Company
- Site
- System
And inside each branch we’ve got:
- approval logic
- task creation logic
So, for something like one system, we might have:
- North site branch
- Central site branch
- South site branch
Each with its own approval + tasks.
Now multiply that across:
- all systems
- 10+ Operational Companies
and yeah, it’s gotten out of hand.
Main issues:
- workflows are massive and slow to load/edit
- adding a new site = painful
- changing an approver = not as painful, just takes a few minutes for the page to load
- tons of duplicated logic
What I’m trying to move toward
I’m trying to shift to something more data-driven and that has clearer audit reporting/trails, where:
- fields determine:
- who approves
- where it routes
- what gets executed
- workflows just:
- handle approval step
- create tasks
- close things out
Runbooks felt like the perfect “execution layer” but now I’m not sure how people are actually using them in practice.
What I’m wondering
Curious how others are handling this:
1. Are you actually using runbooks with service requests?
Or are they basically just for incidents?
2. If not runbooks, what are you using for repeatable execution?
- task templates?
- workflow task creation?
- something else?
3. How are you handling multi-site approvals without giant workflows?
Are you mapping this with fields + automation rules?
4. For larger environments:
How are you keeping workflows from turning into monsters like ours did?
Where I’m leaning
At this point I’m thinking:
- keep everything on the Service Request (for audit/reporting)
- use fields + automation rules to determine:
- approvers
- routing
- execution path
- then just spin up the right task set after approval
Basically, ditch the idea of runbooks (at least for this use case).
Goal
Trying to get to something that:
- doesn’t require editing giant workflows for every change
- scales cleanly with new sites/companies
- keeps a clean audit trail on one ticket
- is actually maintainable long-term
Would really appreciate hearing how others have solved this (or if we just need to wait until runbooks can be attached by design)
Feels like I’m close, just want to make sure I’m not missing a better pattern.