If you post the XML for your page it would help to pinpoint, but it looks like you’re dealing with a context issue.  Buttons are usually tied to a model, and it looks like you’re context is off and when context isn’t set correctly it will pull the first row.  There are different configuration points for defining context depending on the component in use.

Hi John

Thanks for getting back to me,

here is my XML

row.created
























































































<action type=“redirect” window=“blank” url=“https://workday–qa–c.cs23.visual.force.com/apex/TabbedAccountPage?srPos=0&amp;srKp=001&amp…= {{Related_Account__c}}” model=“KeyContact” behavior=“standard”/>











<action type=“blockUI” window=“blank” url=“https://workday–qa.cs23.my.salesforce.com/{{Related_Account__c}}”/>;



KeyContact

Contact







Select Contact to Add as Key Contact


{{Model.label}}

























































<action type=“redirect” window=“blank” url=“https://workday–qa–c.cs23.visual.force.com/apex/TabbedAccountPage?srPos=0&amp;srKp=001&amp…;





<action type=“redirect” window=“blank” url=”https://workday–qa.cs23.my.salesforce.com/apex/Customer360SummaryPage?Id ={{AccountId}}“/>











<field id=“Services_Key_Contact__c” hideable=“true” uniqueid=“fi-3kI_sr-560” type=”" valueh

I’m not sure which set of components you’re landing on as it looks like you’re trying out several different approaches, but here are couple pointers. 

First, you have a model action that is updating the account on the contact detail table with {{$Model.Contact.data.0.AccountId}}.  This will always pick the first record from the contact model.  This may not be causing an issue at the moment given you’re filtering the account via a URL parameter and the contacts should always have the same account.  However I’ve found that it best to avoid this first row reference unless you have a clean lineup to a known single record, avoiding surprises later.  Also there are certainly good use cases for leveraging the action framework from a model, but this probably isn’t one of them.  It’s better to include all the field values you need in a “Create new row(s)” action as one package. 

Second, for what I’m deciphering as your use case, I would use the mass action on your table and expand the action of creating a new row to perform the inserts into the contact detail model.  Move the account update there as well.  The mass actions will have row context for when you pick the items from your table.  While the button component can be tied to a model, it doesn’t have the same row-level context for the records of interest, so it will use the first row.

Another idea is to use a row-action to perform your record update.  You can setup a similar action sequence to create new rows and then the user can click the icon on the row.  It would be one less click that way.  We do something similar to follow records with Chatter. 

In both of these cases, make sure to use the merge fields rather than the $Model parameter so you keep in context.

Hi John,

   Thanks for the details reply, 
Here is what we are trying to do,
We want identify key contacts per account,  So when AE is click a button account, that will bring them to this page which will give them list of Key contacts for that account and able to Tag a contact as a Key contact.

To Tag them ,  They wanted click which will give them all the contacts that are related to that account, and pick the contacts as a Key contact.Those contact will be inserted to a Key contact as new rows then AE can enter more details (which is the create new rows in to the Key Contact) 
First I used Navigation component, which worked perfectly, but in they UI it didn’t look that fancy,
so I tried the same scenario using a button set, which is bringing me only one row.

Thanks for your help.

 

I would start with using a row action to add a row to a model as mentioned above.  Once you get comfortable with context there it should be easy enough to setup a mass action.  I don’t think buttons are the way to go.  Think of these as options for global actions, not mass actions.

I think John is right, and buttons may not be best suited to see which rows your user has chosen. From what you’ve described, you might consider setting up a mass action on your contacts table, which will run actions to 1) adopt the selected rows into a second model and then 2) update the appropriate field on that model to mark them as Key contacts. Once you have adopted the selected contacts into the new model, you have much more freedom to make any changes to them, and it’ll be easier to keep these selected rows together, and separated from the main list of contacts. 

Thanks John/Mark,

  yes, I was able to design the Navigation component as a button that worked like a charm. 

But I have tested with row action which works as well, but I kind a like the Navigation worked.

Anyways thanks for both of your help.