It can, with certain steps. Remember the order of operations in script processing... Roll20 Parsing ==> Metascript processing (loops to Roll20 parsing again) == eventually ==> Destination Script (ScriptCards) The Fetch call will only work after the row is created, which means we're past the main metascript loop. The outbound call to ChatSetAttr (to create the repeating item) initiates a new metascript loop, but there again the row isn't created yet. The Fetch call will only resolve on a chat message initiated *after* the row is created; each new message initiates a new metascript loop. So the easiest solution is to have ScriptCards send another outbound call. To itself. Put everything that SC will need in the downstream command. The constructions that resolve in the original, top-level of the ScriptCard can either be moved (if it's just a matter of assignment of a variable to equal a value) or duplicated (if the variable is derived from some process, and now you just need to track it forward to the new call). Then the only thing you will have to work around is whether the ChatSetAttr attribute creation is handled asynchronously, where command execution returns to ScriptCards before the row is created. You can check this by including a default value in your Fetch call. *^([*S:character_name].powers.[label=Weapons Array].rowid[oh that was bad]) If the default value (oh that was bad) is returned, you know the repeating item wasn't found. In THAT case, you might want to delay the ScriptCard's outbound call to itself... you can do that using Aaron's Delay script. Probably any amount of time is enough to put it at the bottom of the async stack and have it resolve once the row is created.