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.