How to move records from one table to another based on field input?

Generally speaking, if you have records that have the same structure, you would keep them on the same table. Can you provide a little more context for keeping these records in separate tables?

I feel like this thread died out, but I have a scenario that fits this bill. I have a Task and Assigned Task table for a project manager. I would like to be able to check a checkbox "Task Assigned" (After assigning it to a user" and then have that record automatically move to the Assigned Tasks table (with the same fields being imported over). Can this be done?

I'm going to ask the same question that Blake asked.  Why do you have those tasks on different tables?  Especially if they have have similar fields, but basically one changes status...

You could possibly do this with a webhook if you are dead set on duplicating the record.

Thats a valid question, I'm still pretty new to QuickBase, I have them on different tables so that on the user end, they dont have to see the assigned tasks on the requests page, because that would display a huge report of tasks, I want to be able to make it almost like an assembly line and have the tasks populate into the assigned tasks section (which has a two extra fields for developers working on the requests to add notes).

That way the user could see the assigned tasks in a separate report but not be able to edit it once its in the assigned tasks table. 

Again, brand new to QuickBase so I may be missing something obvious here. 

Thanks!

Stepping in as a third QSP here in case Blake and Matthew are off line now.

We all agree.  Control what users see by the reports that they use and their Role permission will control what they can see and edit.

When GM makes a car, it's the same car moving down the assembly line, not a duplicate of the car being created to drop in the next assembly stage.

 You have a lot of tools to work with including form rules and role permissions.

You would be better off to rephrase your question if you are stuck in terms of controlling access to the same records by users in different Roles.

For example, a Custom Role permissions for a Role that says only allowed to edit if the Status of the record is X.  You can also have any complex logic you like by making a dedicated formula field for this purpose called like [Low level Role allowed to edit?] and then the Custom Role permission is when that is checked, then users in that Role may edit.

Note that users in different Roles can be set up to have different dashboards and different tabe Home pages.

I need help with this too.  I have a list of all of our faculty at our school. When they retire, I want to preserve their record and documents attached to that record but move it out of the current faculty to another table.  I am not finding a way to do this.  

A low-tech approach is to use the recently added feature called Actions.

You will find that menu option under settings for the table.

You could have a checkbox that says copy to other table. Then you can have an action trigger when the record is saved and that field has changed and it is set to checked.

Then configure the actions so that each individual field is mapped to the correct field in your other table.

I would suggest that you put a report link field on your main record which will show an embedded report of all of the employees with the same employee number in your archive table. That way you can refresh the main record and see that the archived record was successfully created. Then you can delete the original record manually with confidence, knowing that the archive record was successfully created.

Note that if you do you add fields to your main record, you will also have to remember to create those equivalent fields on the archive record and adjust your Action.

>We all agree.  

No we don't! The original poster wants to use the two tables as an inbox/outbox moving a record from one table to the next and perhaps eventually deleting the record once the work is completed if there is no reason to keep a historical record of how it was disposed of. This is a reasonable workflow and there may be good reasons to structure it this way including security and/or information segregation. It is easy to do with JavaScript.