How to Link Secondary Tables

Methods for connecting secondary tables to other secondary tables in Rayven

Overview

In Rayven, linking tables means creating a relationship between rows in different tables so that related data can be connected, displayed, and processed together.

While Rayven includes a Workspace linking capability for connecting a Secondary Table to a Primary Table (by UID or Label Value), that process is covered in a separate article.
This article focuses on linking one Secondary Table to another, which cannot be done using the Workspace’s table linking options. Instead, it is achieved using workflows and coded logic.

Understanding Secondary-to-Secondary Linking

Secondary tables extend your application’s data model by storing additional, related records. For example:

• A Tasks table may be linked to a Contacts table if each task is assigned to a specific contact.

• A Service Logs table may be linked to a Maintenance Plans table if each log belongs to a scheduled maintenance plan.

Unlike Secondary-to-Primary linking (which is schema-enforced in the database), Secondary-to-Secondary linking is logic-driven:

• The relationship is maintained through shared keys or identifiers (e.g., Task ID, Order Number, Plan ID).

• Rayven does not enforce this relationship at the database level — it relies on workflows or custom logic to read, validate, and write the correct values.

How to Link Secondary Tables Using a Workflow

1. Identify the Common Key

Decide on the field that will serve as the link between the two secondary tables.

• This could be a UID from one table or another unique identifier.

• Ensure that values for this field are consistent across both tables.

2. Query the Source Table

You can read data from a source secondary table in two main ways:

• Using the Query Tables Node
  Retrieve records from a table by specifying the columns and optional filtering conditions. 

• Using getDataFromTable in a UI Code Node
  Call the getDataFromTable function in JavaScript to fetch table data directly within your code. This method is useful when:

  • You’re building a custom interface widget.

  • You need to process or transform table data in code before passing it to other workflow nodes.

  • You want more granular control over how the query is performed and how the results are handled.

3. Process or Validate the Data

Once you’ve retrieved the relevant record(s) from the source table, you should validate and prepare the data before writing to the target table.

You can do this in two main ways:

• JavaScript Node (when data is flowing through the workflow)
  Apply transformations, checks, or conditional logic to the payload before it continues to the next node. This is ideal if you’ve retrieved the data using the Query Tables node earlier in the workflow.

• UI Code Node (read and process in one place)
  The UI Code node supports full JavaScript capability, allowing you to:

  • Use getDataFromTable to read the data directly.

  • Apply processing, validation, and transformation logic immediately within the same node.

  • Output the final result to the rest of the workflow or use it directly in an interface widget.

Using the UI Code node in this way can simplify your workflow by combining data retrieval and data processing into a single step, especially when the linking logic is specific to a custom interface.

4. Update the Target Table

Use the Update Tables node to insert or update rows in the target secondary table.

• Map the common key so the relationship is maintained.

• Include any additional fields that need to be set based on the source table data.

5. Maintain the Relationship

Ensure that:

• The common key remains unique and consistent.

• Updates to one table that affect the common key are reflected in the other table via workflow logic.

Example – Linking a “Service Logs” Table to a “Maintenance Plans” Table

1. Service Logs (secondary table) contains Plan ID for each service entry.

2. Maintenance Plans (secondary table) contains Plan ID and details about the plan.

3. Workflow steps:

   • Query the Maintenance Plans table by Plan ID.

   • Validate the plan exists and retrieve plan details.

   • Write relevant details into the Service Logs table for reporting or display in interfaces.

Best Practices

• Keep key values consistent — avoid manual entry errors by using workflows to populate keys wherever possible.

• Validate before writing — always check that the related record exists before creating the link.

• Use clear column names — name linking columns descriptively (e.g., Linked_Contact_UID) so their purpose is obvious.

• Avoid duplicate keys — if the link should be one-to-one, enforce uniqueness through workflow logic.

Summary

• Secondary-to-Primary linking is handled via Workspace table linking options and is schema-enforced (covered in another article).

• Secondary-to-Secondary linking is done via workflows or coded logic, using common keys to relate records.

• Workflows can query, validate, and update multiple tables to maintain these relationships.

FAQs

Q: Can I link two secondary tables in the Workspace without a workflow?
A: No. Workspace linking is only available for connecting a Secondary Table to a Primary Table.

Q: How do I prevent mismatched records when linking two secondary tables?
A: Use workflow or Javascript logic to validate that the target record exists before writing the linked value.

Q: Can I link using a Label Value instead of a UID for secondary-to-secondary links?
A: Yes, if both tables have the relevant label column and values, but this relationship will not be enforced at the database level.

Q: Can I update both linked tables in a single workflow?
A: Yes. You can query one table, transform the data, and update both tables within the same workflow if required.