I have a workspace that includes entities (tables) for:
People (contacts)
Money (a log of money coming in and out)
Content (forms and images)
General (A 1-record table that includes details, such as client name and social links)
Budget (budget items)
Events (events and todos)
The space is used for management of a single customer. (A political campaign.) Many of the values come in and get modified via GraphQL API calls, which require a workspace target.
When I did this in Airtable, I would duplicate a workspace and then update the API references to point to the new workspace.
Iām not seeing an obvious way to duplicate this structure so that I can have one per customer, and call them independently via the API. I was hoping the Share Template option would let me do this, but it errors because Iām trying to āshareā the new workspace under the same account.
Is the Clone Script method how to do this? Iām unclear about what that describes in the docs and Iām nervous to try it without clear understanding.
I am curious why you want to duplicate the space? This seems like a classic case where you ought to store all the data in a single space (including a db of Customers in addition to the ones you listed) and then just use smart folders and/of view filtering to limit to specific customerās records as needed.
In addition to not knowing how I would determine via API calls which campaign/customer a new or updated record would be associated with, I also have to create relations within the UI that are based on those values. Also, I have to add additional users who should have edit access only to their own campaigns.
When a donation comes in from the website and I have the email of the donor, I need to apply it to the correct campaign, based on the originating website. If the person doesnāt exist, I need to create that People record and then create a Money record and link it. I have no idea how I would do that and keep things isolated between campaigns.
I have watched the Smart Folder videos and read the docs, but Iām not getting at all how this avoids the need to duplicate a space when you need a firewall between records in the UI and via the API.
Example of the problem Iām seeing:
A people record is created when someone endorses a candidate. The People record is updated with that endorsement indication. That person has NOT endorsed other candidates, but there is no way to indicate that without adding new People fields for every possible endorsement option. I could go with creating duplicate People records for each endorsement offered by the person, but when that person later sends a donation via the API, I need to search the People record for the instance of that person connected to the campaign website from which it came. Unless Iām missing something, this is going to make the backend function much more difficult.
Then thereās the issue of having 20 or more views per table, and being able to restrict access to each pseudo-space by user. This seems like itās going to be a mess in the smart folders section, in terms of the candidate (who isnāt tech savvy) being able to navigate and edit things.
By contrast, if I could simply duplicate the space, then I just update the space reference in the API calls from each website, and share the space with a specific candidate, and Iām done. (This is the way I did it in Airtable.)
Whatever you can do to the data via API, you can do via UI, and vice versa.
I would think that when you have a donation coming in (created via API or via UI) you would create a entity in the Money db.
And yes, when the donation comes in, you would need to query the Donor db (I guess thatās your People db?) to see if the donor is already known to you. If they are, link the Money entity to the correct existing Donor entity.
If not, create a new Donor entity and then link the Money entity to that Donor.
Also, each Money record would have to be linked to an entity in a Campaign db, to indicate where the donor intended the money to go, assuming the incoming donation includes information about the campaign this money is going towards.
It may well be that I misunderstand your data types, but I think starting from a well-defined schema will allow you to avoid duplicating spaces.
Something like
Person ā Money (1:m relation that represents a person giving money, maybe multiple times)
Money ā Campaign (m:1 relation that represents money being attributed to a specific recipient campaign)
You can then use API calls to create entities, but also define their relations to entities of other types.
You donāt need to think about āpseudo spacesā. You can restrict users to only seeing specific entities (and related items) and not grant access at the space level.
So for example, you would allow the candidate access to their campaign entity and all the donations linked to it. They wouldnāt be allowed to see any other donations that are unrelated.
And a top-level smart folder in the sidebar would only show the candidate the campaign they are allowed to see (and its nested context views). Whereas when you (as admin) log in, you would see all campaigns in the sidebar.
Maybe check out these guides:
Having said all that, if youāre adamant that you want to split the data by spaces, itās very easy to clone a space, but you canāt have a naming clash, so you need to rename the source space aftergenerating the space sharing template and before creating a new space from the template.
Thank you! This is what I needed, and the need to rename the source is why it wasnāt working for me.
There are just too many laws related to campaign finance and management that would have made it way too complicated to try do this all based on filtering values. For example, per-campaign donation limits: If someone donated $50 to one campaign and $100 to another, the rules related to the info that must be collected and reported are different. I could see myself having to manage a bunch of bridge tables just to define the different relationships between records across tables.
Plus, I have campaigns that go back 7 years. Once an election is over, the data needs to be archived in the state it was when the campaign ended. If I had a single person who had donated to multiple active campaigns, it would be confusing trying to determine when that record was āArchivedā versus when it was current with another campaign.
I realize that duplicating data is never the sexiest option, but campaign finance laws in the US are very strict, though you wouldnāt know it by what a mess our government is right now! If I were to get an API call wrong, and the wrong expense or donation was assigned to the wrong campaign, I could be in big legal trouble. The āfirewallā (unique spaces) approach is just so much easier for me to manage. In the future, if I get so comfortable with Fibery that Iām willing to take the risk and figure it all out reliably, Iāll come back here to thank you for that pointer.
