Data is not stored in "layouts". Data is stored in tables and any given database can have any number of layouts that all reference the same table.
Can you describe what you want to do in more detail and why?
Users can easily find a record in a database and then modify the fields in that database--with record locking preventing other users from modifying the record until they commit the changed record back to the database. So it's not clear to me why you would need to copy any data to a different location here, though such operations are possible.
I have people working landscape. They use specific layouts to check to-do lists and select which job they did at that persons house. I want my manager to be able to clear this information after the day is over so that when the user comes back the next week, he starts all over again selecting the appropiate info for a new job. Even though my manager cleared the info from this page, it is still being stored on another page to keep record of that persons past jobs. Does this help?
The system can simply start a new record when the user comes back next week. This would produce the same result on your screen, but without the need to copy or delete any data.
But if he adds a new record instead of deletes the data then the user doesnt know which one is the current job, it becomes a mess since the records dont stay where they left off. Do you know of another way to go about this then?
You still need to keep those records.
They should include a field that auto-enters the creation date and/or a serial number. Your layout design/scripting etc can use such fields to control what record the user sees to avoid any such confusion. A field in the record can also record the status of that job as a way to keep track of which jobs are current and which are past.
Please keep in mind that FileMaker can do what you describe, it's just that it is an unecessarily complex way to go about managing your data.