The container that has the signature can only belong to one record. What you can do is introduce the concept of a batch of jobs. The batch is a table, it has the signature in a batch record. All signed jobs share the same batch id.
If you need to authorize the work instruction and want to show the signature for every associated job, put the container in the work instruction table.
1 of 1 people found this helpful
I agree with the other poster that a related table should be used, but technically a global field can be used across all records. Working with Global Fields | FileMaker
Technically yes, a global field could be used, but this would basically approve all tasks both past, present and future with a single signature. That then works from a data base perspective, but might not be what you want from a business practice perspective.
Thanks for the responses, I'd totally forgot about global fields, which is more than adequate in this instance, the jobs will only be imported as once I've authorised them so the only records showing will be those that have been authorised anyway.
Having tested this it works in this scenario perfectly fine but having a related table would probably be the better solution if I was uploading jobs that hadn't already been approved.
Thanks for the responses, I'd totally forgot about global fields, which is more than adequate in this instance,
No it really is not!!!!
Don't use globals for this.
Can you explain why?
The ONLY records on the system are approved, it doesn't matter whether they are pending, complete, delayed or cancelled, they are ALL still approved, it doesn't even matter if they never get completed for whatever reason?
I genuinely don't understand why just using a global field isn't sufficient in this instance?
A couple of reasons:
1- globals are meant for non-persistent storage and while they can forced to be persistent it is against their nature
2- globals are meant to be user-specific so if one user changes the value it will not change for any other user. Same caveat as #1
3- a global can only have one value for all the records in a table. That means that if you force them to be persistent to counter #1 and #2 you could really only capture one signature ever in the lifetime of the database. Or you'd overwrite ti the next time which does not make sense at all, why capture the signature in the first place then if you can't track who signed for what and when.
Note that 1 and 2 in Wim's list apply to hosted solutions. They don't apply to a standalone single user solution--but keep in mind that many hosted solution started out as a stand alone solution that "grew up" into a hosted multi-user solution...