function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Looking for ideas on how to streamline Opp Edit to include Competitors/Opp Contacts/etc.

Once the users have completed editing their opportunity data, they tend to forget to scroll down to complete opportunity competitors, opportunity partners, and opportunity contact roles.   We would like to create a single screen in which edit both their opportunity and to add competitor records, partner records, and opportunity contact role information. We have multiple record-types based upon profile, so a means of factoring this in would need to be accomodated.  We would like to ideally embed edit capability for these other related list records within the main edit screen within their own scrollable sections (i.e. users could edit one or more lines of competitors, partners, contact roles each in their own section) and then have a method of updating all of these entities upon a single save. 


I am looking for some approaches that might be viable to solution this.  We have Apex experience, and very light VisualForce experience (i.e. can create a VF to represent a custom edit screen or view screen for a single object, have created standard controller extensions and custom controllers, however no experience in creating embedded scrollable input sections like described above).  Open to alternative approaches as well that would have the same net effect of ensuring users are presented with these sections to edit.


A few ideas I've used for similiar reasons.


1. Wizard setup - This is either a multi-page or a multi-output panel layout. Each step that you want users to "add" related objects goes onto a page or multi-layout. This way, the user doesn't have the option NOT to see the "add related object" option as they go through the wizard. This is best used on creating new objects, since being forced to go through the whole wizard when they just want the close date updated can be a pain.


2. Single page method with validation rules. This approach is similiar to the above - but can require a long page of code (which I had to manage, I prefer separate pages). You can use a custom class or a class extension to let users edit the Opportunity, and related objects. You can have a "save" button for the opportunity and a "add" button for each related item. To leave the page there's a "complete" button. When that button is pressed, it goes through a series of validation rules and returns an apex message (validation error). This is where you place requirements that you have to have a contact role, or a competitor or whatever your internal requirements are. This means the user cannot complete the edit until all validations are met.


For a massive edit - you may want to re-think this option. Every related list is going to have to be placed into a data table to manage multiple-objects. If you have a lot of related objects and/or a lot of records this page can become very long and almost unmanagable for the user.


One of things I do before moving forward on these projects is to make a mock up. I'll take some screen shots and carve them up in Paint (or photoshop) and duplicate what a user would ultimately see. I find this visual exercise pretty useful. First it gives me an idea of feasibility and the amount of work required. Second, it gives you something to share with your end users and return feedback on functionality prior to coding. Getting these issues right away is always better than finishing all your code than being told that it doesn't work for the end user.


Good luck! I'll be interested in seeing what you end up doing.


Thanks Brian.  It's always good to have a sounding board for these ideas as most ideas have already been attempted by others in some form.  Both concepts have merit - multi-page is definitely easier to maintain, however as stated it can be a challenge if the user only wants to update a date or $.  Our experience has been that sellers don't always know some of the related list info at time of initial opportunity creation, so while a wizard can help them, it often isn't populated on first pass.  I agree that stuffing all into one screen can be onerous, and with the large number of fields we already have on our opportunities it's likely to get lost in the clutter. 


Another idea that I came up with revolves around action buttons on a custom edit screen that will allow the user to 'Edit Competitors', 'Edit Partners', 'Edit Contact Roles', etc. so that the user can technically stay within edit and use these action buttons to expose other areas to edit upon demand.  We always mock-up and review with key constituents so that we aren't delivering unacceptable functionality.  Thanks again.