Where Do Goals Actually Live in Blueprint?

Blueprint and App Design Knowledge Share
1

Quick truth for anyone new to Pega Blueprint (and a good reminder for the rest of us): there is no dedicated “Goals” field — and there doesn’t need to be.

Where goals actually live: Application Purpose + Functional Description. That’s the one and only place.

Business objectives, success outcomes, and constraints belong directly in the Purpose narrative. Blueprint’s GenAI reads your Purpose, infers what to optimize for, and uses that context to shape everything downstream: case types, stages, personas, and agent recommendations.

Translation: vague Purpose = vague design. Sharp Purpose = sharp design.

The trap

Because there’s no “Goals” field, most of us either skip goals entirely or bury them in a companion doc Blueprint never sees — then wonder why the generated design misses the mark. If Blueprint can’t read it, Blueprint can’t optimize for it.

Below is 1-page quick reference that covers:

  • :white_check_mark: Where goals go (and where they don’t go)
  • :brain: How Blueprint reads and uses your narrative (it reads → infers → uses)
  • :writing_hand: A simple 4-part framework for writing a Purpose statement Blueprint can use — Objective, Success Outcomes, Constraints, and Automation Opportunities — with a real example for each
  • :light_bulb: 3 practical takeaways + common pitfalls to avoid

image
image660×807 177 KB

Save the card for your next Blueprint kickoff. Then drop a comment: what’s the sharpest Application Purpose statement you’ve ever written — and what made it click?

2 Likes
2

Can you please elaborate why there is no dedicated Goals field?

If this is so important to define goals, wouldn’t it be more effective to have dedicated field?

Otherwise app creators need to do some “prompting black magic” and hoping that LLM will obey it. Which might not be the case if each user specifies goals differently without strict schema.

3

Great question. I don’t think it’s because goals are unimportant. Rather, Blueprint was designed around application context and business narrative instead of a separate goals object. The Application Purpose and Functional Description provide the intent that GenAI uses to shape workflows, personas, and recommendations.

That said, I agree there are valid arguments for a dedicated Goals section: consistency, visibility, and more structured inputs.

The current tradeoff appears to be flexibility versus structure. Today, the recommended approach is to explicitly capture business objectives, outcomes, constraints, and automation opportunities directly in the Purpose/Description so Blueprint can actually use them.

Personally, I’d welcome a dedicated Goals section in the future—provided it still feeds the Application Context that drives Blueprint’s AI. That would give us the best of both worlds.

2 Likes