How Hookshot Works

What this is

This page explains the customer mental model for Hookshot without diving into internal architecture.

When to use it

Use this page when you want to understand the sequence from incoming event to verified outcome.

What you need first

• Familiarity with the terms in the glossary

Steps

1. Something starts the workflow

A Protege starts because of:

• A live event from an integration, or

• A schedule you configured

2. Hookshot checks whether the Protege should act

Hookshot looks at:

• The available trigger source

• The Protege configuration

• The connected tool access needed to complete the task

3. The Protege runs or is skipped

Possible outcomes you may see:

• ran: the Protege executed

• dispatching: the event is still in progress

• skipped: Hookshot chose not to run the Protege for that event

• unevaluated: the event has not reached a final usable state yet

4. You verify what happened

• Use Event Feed to confirm the event arrived and see the immediate status

• Use Audit to inspect the run and outcome

Event Feed answers “did Hookshot see the event and what happened next?” Audit answers “what did the Protege actually do?”

How to verify

You understand the model well enough when you can point to:

• The system that starts the Protege

• The condition that decides whether the Protege should act

• The product section where you will confirm success

Common failures

• Looking only at Audit when the event never arrived in Event Feed

• Assuming a connected integration automatically means the trigger source is ready

• Confusing a visible event with a confirmed successful run

Next step

• Create a Protege

• Event Feed

• Audit