There are indeed certain script steps which require a field to be on the active layout. GoToField is one of them.
by not going to that field (-:
no field means nothing to go to - but: Just use 'set Field'
There are script-steps that need a field on a layout, others don't. Set Field works without a field in a layout, copy, paste etc. do
Not sure, what You want to do, so a more specific answer is not possible
2 of 2 people found this helpful
I'm going to disagree with the other replies (slightly). Table view is a unique kind of "layout". If, for example, you have a layout (Form view) with fields, you can toggle to View As (Table) then Modify to have different fields than are on the Form. Same layout, different views.
I just tested:
1. On the Form view for a layout, I placed a "phone" field then left the label, but deleted the field. Go to Browse mode.
2. Then I toggle to show the Table view. With the correct permission, you see "Modify" button in the upper right.
3. Click & add the "phone" field to this and enter Browse mode again.
4. 'toggle' the views to verify the field in Table view and not in Form view
5. Create a simple script to:
Go to Field ( Select/perform ; Contacts::phone )
6. Test this in Form view and you will get the error
102 Field is missing
7. Test again in Table view and you will not get the error!
So, YES, the field must be on the layout, but Browse mode Table view of a layout isn't necessarily what fields are on the layout in Layout mode or in Browse mode with Form View.
Go to field, go to object, Copy, paste, clear and script steps that start with the word "insert" all fail to work if the field specified (or layout object specified for go to object. ) is not on the current layout (or part of the table view). This failure will return an error code but will not interrupt your script with a error message. Thus, a future layout change (or modifying the table view) can cause a script to fail and unless the user observes a result that indicates that the script failed, they might not even notice that it did.
In addition, these steps all cause a change in focus that can trip multiple script triggers. Thus, a future modification that adds a trigger can result in a triggered script interfering.
Fot the above reasons, it is best to avoid using those steps whenever possible. When you do have to use one of them, it is a good idea to help your future self and any fellow developers by clearly documenting the fact that these fields must be present on the layout. In some cases, you might set up a utility layout used by your script with a chunk of layout text in place to tell developers: "This layout is used by script ABC, do not modify layout without checking script."