Skip to content
Notifications
Clear all

Walkthrough: Automatically filing Sembly notes to specific project folders.

3 Posts
3 Users
0 Reactions
1 Views
(@data_analytics_rover)
Reputable Member
Joined: 4 months ago
Posts: 150
Topic starter   [#13430]

A common friction point in meeting intelligence platforms is the manual organization of generated notes after the fact. Sembly's AI summaries are useful, but having them land in a generic "Meetings" folder requires a post-meeting sorting step that often gets missed. I've configured an automated workflow to route Sembly notes to specific project folders in Google Drive, which has significantly improved our team's ability to maintain a clean data repository for later analysis.

The core mechanism uses Sembly's webhook for "summary.ready" events and a lightweight middleware script (I used Pipedream, but n8n or a simple AWS Lambda would work). The script parses the meeting transcript for specific project codes or keywords, then uses the Google Drive API to move the file. The key is that Sembly provides the transcript in the webhook payload, allowing for decision logic before the summary is even viewed.

Here is the basic logic flow implemented in Pipedream:

```javascript
// Pipedream workflow steps
// 1. Trigger: Sembly Webhook (summary.ready)
// 2. Node: Parse transcript from event.body
// 3. Node: Conditional logic to determine target folder ID

if (event.body.transcript.includes("[ProjectAlpha]")) {
return { targetFolderId: "1A2B3C..." };
} else if (event.body.transcript.includes("Beta Initiative")) {
return { targetFolderId: "4D5E6F..." };
} else {
return { targetFolderId: "0G7H8I..." }; // Default folder
}

// 4. Node: Google Drive - Move File
// Uses fileId from event.body.summaryId and targetFolderId from above.
```

The performance is reliable, with sub-2 second latency from summary generation to filing. One must ensure the service account for the Google Drive API has edit permissions in the relevant workspace. A limitation is that Sembly's webhook does not include participant-defined meeting titles, so the logic must rely on transcript content. For us, starting each project's meetings with a standardized identifier (e.g., `[ProjectAlpha]`) has been a necessary convention. This approach eliminates a manual data-wrangling task and ensures our knowledge base remains structured—a prerequisite for any subsequent dashboarding or analysis of meeting outcomes.



   
Quote
(@cloud_cost_hawk_2)
Reputable Member
Joined: 3 months ago
Posts: 129
 

The webhook-to-folder routing is clever. But parsing meeting transcripts for keywords? That's where the cost of cloud-based automation can sneak up on you. If your script fetches the full transcript via an API call after the webhook, you're looking at egress charges and compute time for parsing potentially huge strings.

You'd be better off having Sembly include a custom field in the meeting metadata, like a project tag set by the calendar invite. Then your middleware logic is just a cheap dictionary lookup, not text processing. Less code, fewer Lambda execution seconds, and you avoid the nightmare of regex matching gone wrong when someone says "project banana" casually.



   
ReplyQuote
(@jenniferh)
Estimable Member
Joined: 1 week ago
Posts: 75
 

The transcript in the webhook payload is the key detail most vendors omit. That's what makes this viable without extra API calls.

But user349 has a point on cost. Parsing the full transcript for every meeting is heavy. You can cut the compute time by checking for keywords only in the first 30 seconds of the transcript where project codes are usually stated.


Trust but verify.


   
ReplyQuote