I’m building a LinkedIn prospecting CRM in Tinderbox. Each prospect note lives in Connections Raw and has a $LinkedinURLattribute. Each message note lives in Messages Raw and has a $MessageKey attribute containing the LinkedIn URL of the non-Ted party. I need some representation of each message to appear inside its matching prospect’s container, where the match condition is $MessageKey == $LinkedinURL.
The purpose is to keep track of communication with each prospect. The message notes contain the actual exchange — who said what and when. Having them visible inside the prospect’s container makes it possible to see the full history of a relationship at a glance, and to maintain running counts and dates of inbound and outbound messages per prospect.
In an earlier attempt, my agent ended up moving matching notes into prospect containers. That caused damage: the move changed a note’s container, which caused the agent to re-evaluate, which sometimes moved the note again or created conflicts between overlapping agent scopes. The cumulative result was structural corruption severe enough that Tinderbox would hang on open.
Would aliases solve this cleanly? Specifically, could a document-level agent create aliases of matching message notes inside each prospect container, based on $MessageKey == $LinkedinURL, without the structural risks of physically moving notes?
Yes, in principle. What I’d do first is to make some raises manually and place them where you think they should be to test:
if the bias answers the need expressed
the other needed for the new aliases.
As regards the alias, for this task it can be anywhere, as long as:
you can define a query can find all the notes that need associated alias(es). As long as you don’t use very terms that are relative to the agent location it doesn’t matter where it is.
the action for matched notes is possibly complex. So, for each matched note:
find via (??? data) the associated notes that need aliasing, a list of one or more notes.
using the context of the matched note’s original as the target for the alias location (as a sibling or child), for each listed source note for an alias, make that alias and move it (set $Container) such that the alias in the correct position.
you will logic to know when a prospect has been processed and so is excluded from the agent query, so likely a completion boolean set.
Start the tests small with one prospect and one message and then move up to multiple messages and then multiple prospects. This has the fell of an agent you might disable when not in use so it’s not constantly messing around with aliases. Turn the agent on when needed and let it drain its current due of matches that self-unlatch once they’ve been processed.