I would like to have the ability to create a number of different documents (from templates) based on parameters on my “Admin” doc. For example, I would be able to select the ‘employee’ and the ‘doc type’ from select menus, and use those as parameters for my createDoc(employee, docType). This would then create a copy of the template (invoked by docType), customized to the specified employee.
Is this something that anyone has done? I am open to all tips, I’m very much a n00b.
Thank you!
Yes! You absolutely can do it. I’ve done almost the exact same thing and have the pack working for a client.
You just need to create a pack for it. Have you built Packs before? Whats your Javascript knowledge like?
Thanks so much for the quick help, Scott! I have a little experience in packs and minimal javascript skills. What I’m currently hung up on is the language inside the formula itself. I’ve been able to just copy template scripts to create the rest of the structure but am not sure where to look to find documentation on telling Coda to create a new document. Do you have any tips? Thank you!
Unfortunately you won’t be able to do that directly within Coda and with native features itself, you would need to develop a pack for it.
The pack-studio is very friendly to those who have minimal javascript knowledge and the community is extremely helpful as you make packs of your own.
@Eric_Koleda is a developer advocate at Coda and can also provide TONS of resources. @Thomas_Baucom is another individual who also has started to build packs with little to no Javascript knowledge prior and can definitely give some tips!
If you need it built fast though or don’t have the time to sharpen your Javascript skills, your best bet would be to post in the #marketplace:requests-gigs channel so that someone could make it for you!
Let me know how else I can help!
3 Likes
Curious Scott, did you use the Coda API in a pack to achieve this?
Yes I did sir!
I’ve built a couple iterations of them for myself and for clients
… Coda Pack, Coda API
Yep, thought so.
In @Sarah_Heyborne1’s case, she’d have to learn not only enough Javascript to build a pack, but another steep climb awaits with the Coda API. Certainly this is possible and we can see the light at the end of that tunnel, but for most users, this is a big bite of the apple.
I also think this is likely a nice opportunity for a Pack developer to make a universal solution to automated document creation and permission settings. Although @Sarah_Heyborne1 didn’t stipulate this, it would seem that assigning ownership to the target user might also be beneficial, although I have not thought through all of the security aspects of doing that. I don’t think the API supports this, but I haven’t really looked that closely.
This requirement certainly seems worthy -
- Given this doc (or template) ID…
- Build a copy of it…
- Customize it…
- Share it (or grant ownership) to a given user ID.
For a variety of use cases, this would make the life of Makers more automated and allow my laziness to shine through.
1 Like
Haha challenge accepted - Ill try to take my more private/specific packs and make them available for general use.
There are SOME hiccups . . . But let me look into it
Also happy to make it for you @Sarah_Heyborne1 if you want to chat about that, send me a DM or shoot me a message at scott@simpladocs.com
1 Like
I’m bumping up against this same need right now, and agree that it would be great to have a general-purpose Pack for this. Should I make it? I need to make it for myself anyway…
What’s the best architecture here - do I have this right?
- Pack formula in CFL:
CloneDoc(sourceDocIdOrUrl, newDocTitle, folderId, data)
, where data is an optional JSON object with the following structure:
[{
tableIdOrName: ...,
additions: [{ // rows to add
column: ...,
value: ...
}],
edits: [{ // edits to existing rows
rowId: ...
values: [{
column: ...,
value: ...
}]
]
}]
- Pack code flow (Coda API):
- Create the clone with
POST /docs
- Hammer
GET /mutationStatus
until it confirms the doc creation is finished
- Parse the JSON and apply the changes with
POST
or PUT
to docs/{newDocId}/tables/{tableIdOrName}/rows
- Return the URL of the new doc (or perhaps an object with further doc info?)
Notes/thoughts:
- We’re only allowed to change tabular data, not canvas content, cause API doesn’t let us right? I guess we could somehow let people create a new page in the new doc… should we? I also see there’s a new API feature coming soon to edit the initial page, maybe we wait for that…
- This thread includes a request to have permissions management included as well. What would the best approach here be? Let users pass a single email address and give it write permissions with
POST docs/{docId}/acl/permissions
?
- I’m concerned this CFL formula is getting soooooo complex. We can make everything optional but I’m worried about the intimidation factor.
- Does it make any sense to get webhooks involved here somewhere, rather than pushing everything through that JSON object to the API?
@Scott_Collier-Weir thoughts? And any battle scars you can share so I don’t bump into the same issues you alluded to?
Hey Nick!
I don’t think you need any special packs for this
Just create new docs using the functions of either the Doc Explorer pack or the Coda Doc list pack
Then, send data to the newly created templates via webhook.
You Can programmatically predict what the receiving url or a webhook invoked automation will be of a newly created doc if the doc template already had a webhook invoked automation in it
This allows for fully automated creation of new docs and the population of unique data in these docs
Ah ok yep, that sounds like the best solution. I haven’t messed with webhooks yet but if the webhook URLs are predictable that’s great. Are there any issues with API lag where the mutation webhooks will fail because the doc hasn’t finished creating yet?
Yeah there can be, but I’ve noticed it to be minimal.
You could use Leandro’s scheduler pack to just populate 2 min later just in case haha
Hmm yeah. Cause if I’m automating all of this, that means I’m going to be triggering the webhook like immediately after I fire the doc creation command, so it seems like it might happen a lot? 2min is unfortunately a bit too long to wait from a UX perspective in my use case. I do need it to be kind of “as fast as possible without failing the webhook.”
CFL has no built-in delay functionality. But do you know if RunActions() waits for each step to complete before moving on?
RunActions(
Thing1(),
PacksCallThatTakes10Sec(),
Thing3()
)
When does thing3 happen? a few ms after thing1, or 10 seconds after?
RunActions() should, in my knowledge act like an await in JS, allowing each to complete before running onto the next action
But, I believe that with the “creaeDoc()” call it would likely wait for the creation act to finish, but not necessarily the whole doc completely being created if that makes ANY sense.
Could you just re-fire the webhook over and over until it’s successful?
@Paul_Danyliuk any ideas?
K confirmed yeah, they wait.
I made a Delay Pack just in case some others need it in future:
Then I discovered _Delay()
hidden formula so will probably use that but
1 Like