Automating the new record share Permissions

[Jason]

Following Leo’s announcement I thought it would be interesting to look at automating his Payslips example.

In the shared section of the sidebar – records can be grouped and opened in one app

Before: New feature: [ShareMenuAnyoneWithSharedContent] Result: We are sure this new feature will make all of us rethink how we create use cases in Tape, making shared records more intuitive and organized. Let’s start with an example: managing pay stubs for your team. The challange In the past, managing tasks like handling pay stubs came with certain challenges. Here are three common approaches we’ve seen: One main app syncing with automations to each employee…

What I am going to show here is currently in beta and I maybe shouldn’t be showing it but I think it is just too good not to.

Tape's new record share automated

We need to be able to create the payslip record and then automatically share the record with the correct person on the correct date so that payslips can be prepared in advance.

For this demo, I have created two apps:

1. The Payslips app:
   
   
2. A people app:
   
   

In our Payslips app, we build an automation:

1. We trigger on a set day of the month
2. We need our Tape API key for this automation as it is still in Beta.
3. Search the Payslips app for all the payslips that are due to be published
4. Get the related person’s records
5. The complicated bit happens now in the script block
   
   

We need to get the relevant person’s email address for each of the payslips and this was the easiest way I could think to do this without loops, although there could be a different way.

1. We need our two collections into one.
2. we need our inputs formatted in a certain way so we build a JSONata evaluate string to do that this is where the merging of the two collections comes in the tricky part is getting the relevant email address from the related record. When a record in your collection has a related field Tape gives you the related record ID and a title which is what is displayed in the related record box on the record:
   
   
   
   but we need the email address to do that we use this:

"email": people[record_id = $v.fields[field_id=519428].values.value.record_id].fields[field_id=519424].values[0].value,

What we are doing here is first of all finding the relevant ‘person’ via the record_id that matches the one given in our Payslip record person relation field once we have the relevant person we extract the email address and add it to our Inputs
3. This part runs our evaluation and puts our new object in a variable to be used in a bit it ends up looking like this:

{
  "inputs": [
    {
      "record_id": 130458479,
      "add_permissions": [
        {
          "email": "fred@jmc.tools",
          "permission_level": 2
        }
      ]
    },
    {
      "record_id": 130167551,
      "add_permissions": [
        {
          "email": "jason@jmc.tools",
          "permission_level": 2
        }
      ]
    },
    {
      "record_id": 128371451,
      "add_permissions": [
        {
          "email": "elara@jmc.tools",
          "permission_level": 2
        }
      ]
    }
  ]
}

4. we set our API Key
5. we use the new batchupdatePermisions to set the permissions

---

Other use cases of this could be a support desk record where you only want the specific user seeing the record, a Staff member’s record where they can update their address etc. and I am sure many others.

It is worth noting that If you are sharing one record at a time for example the support call record this is far simpler as you can get the related record details for a single record which gives you access to the email address directly.

[Leo]

Hi @Jason,

what a great example of new use cases that become possible with the permission upgrade! As always, easy to understand and perfectly presented. The idea of providing an app with people to set the permissions in this way is also exciting.

Thank you very much Jason, this is definitely very valuable for the whole community and could also be especially interesting for @roman to solve his use case he posted here.

Best regards
Leo