linkedin-event-attendee-monitor

Template placeholders

• {{EVENT_NAME}} - The event you are monitoring, by its full public name.
• {{EVENT_SEARCH_QUERIES}} - The phrases and hashtags people use when posting about it (event name, short name, hashtags, " ").
• {{DEDUP_RECORD}} - A record your workspace can write to on every run, used to store already-processed post URLs (e.g. your own company's account record).
• {{ATTENDEE_TAG}} - The tag applied to companies found attending (e.g. " attendee").
• {{ALERT_CHANNEL}} - The Slack channel where alerts and drafted copy land.
• {{ALERT_OWNER}} - The person tagged on ICP-fit alerts, who owns the LinkedIn follow-up.
• {{ICP_DEFINITION}} - Your ICP segments, their revenue/employee thresholds, and the buying-committee personas for each.

Purpose

Find people and companies publicly posting on LinkedIn that they are attending {{EVENT_NAME}}. Companies go on a running watchlist. People get checked against your full ICP bar. Fits are routed to a human rep to like, comment, and send a connection request, because the agent cannot perform any of those three actions itself.

Step 1: Search for new posts

Run the harvestapi/linkedin-post-search Apify actor (actorId: harvestapi/linkedin-post-search) with:

• searchQueries: all of {{EVENT_SEARCH_QUERIES}}, run together in one call.
• postedLimit: "3months" is too wide. Use postedLimitDate if narrowing further is possible, otherwise use postedLimit: "week" and rely on dedup (below) to avoid reprocessing. If the trigger is running every 3 days, "week" gives enough overlap to not miss posts between runs.
• sortBy: "date"
• maxPosts: 40 per query (adjust up only if volume clearly exceeds this)

Step 2: Dedupe

Store the running list of already-processed post URLs in {{DEDUP_RECORD}}. Pick a record this workflow can reliably write to on every run (org-level memory is often admin-only and not available to a scheduled run).

Use a clearly labeled section, e.g. "### {{EVENT_NAME}} - Processed Posts", with one line per processed post: date + URL. Before acting on any post returned by the search, skip it if its URL is already listed there. After processing a batch, append the newly processed post URLs (with date) to that section. Prune entries older than 14 days on each write, since the search window looks back one week and runs happen every 3 days. There is no need to retain more than that, and this keeps the note from eating into the record's memory budget.