6

Opportunity Team Members cannot be created unless you are the owner of the Opportunity or are above the role hierarchy. However, there are two ways you can achieve this: 1) Create a Visual force page and then have the logic to add/delete Team Members 2) Create a custom object and write a trigger on the custom object to add team members. Since triggers run ...


4

I think what you're describing is Opportunity Sales Teams, which is different from Roles. This allows defining a specific group of users as part of the Opportunity Team. The Owner can control what level of access Team Members have. Here is an overview: Opportunity Teams. You just need to Enable Team Selling to get started.


4

You can simply append your query with an additional where part that filters out inactive owners as following: WHERE Owner.isactive = true


3

The field cannot be written to, because it is listed as "creatable" only. You must delete the old record and create a new record.


3

Above code seems to be fine, but you need to add Test.startTest & Test.stopTest in testmethod before system.runAs. And you can also use testMethod instead of @isTest annotation for method definition. For e.g. static testMethod void unitTest() { Opportunity opp = new Opportunity(); opp.Name = 'Testing1'; opp.CloseDate = Date.today() + 30; ...


3

Contact Roles is indeed the prescribed solution. You cannot make it mandatory upon opportunity creation, unless you create a Visualforce page for creating new opportunities. You could block the opportunity from moving to a next stage unless Contacts ar linked to the Opportunity. For this you'd need a trigger on Contact Roles that updates a field on ...


3

AFAIK you cannot create a sharing rule at runtime. But yes you can share the opportunity to the user (which as per you question is a field in the oppty). You can insert a record in the opportunityShare object which will give either read or write access. You can add the below code in the an after insert trigger / after update trigger of opportunity. ...


2

Roles expand user permissions to access to records beyond what their profile would normally allow. Generally speaking, Salesforce makes security as restrictive as possible using profiles, then uses roles, sharing rules and permission sets to expand access to objects according to the needs of an organization. Profiles and Roles aren't something I can ...


2

There's a field on User named IsActive. You'll need to test to see if that field is set to True. If a member is set to False, you'll need to remove them from the Opportunity before cloning it.


2

If you share Opportunity or any standard object record with a user or his role.All users in above hierarchy will have access to that record. you can disable the Grant Access Using Hierarchies option for a custom object. But You can't remove Grant Access Using Hierarchies for standard objects.


2

Try using something like this: Select ownerId, Id, (select id, accountId, account.ownerId from AccountTeamMembers ) from account From this you can get all TeamMembers of an account, then change the owner of the accounts. You can not directly change the owner of all teamMembers, because TeamMember doesn't have an owner.


2

This is "as designed" behavior. From Considerations for Customizing Opportunity Teams: Validation rules and Apex triggers aren’t supported when a user adds his or her default opportunity team on an opportunity. This is one of the relatively small number of operations on which triggers are not supported.


1

As some of the cases failed to trigger the Apex Trigger, I did found little mentioning of why they are failing. This Article mentions: Validation rules and Apex triggers aren’t supported when a user adds his or her default opportunity team on an opportunity. What else I found out is that even the Process Builders failed to get the trigger along with Apex ...


1

@DanielBallinger I was able to find a reference to the inconsistent behaviour for OpportunityTeamMember when an Opportunity Owner changes are made from the UI versus the API. As per the Salesforce SOAP API Developer Guide "The behavior for changing ownership of opportunities is different using the user interface when the previous owner is on an ...


1

So I've finally found the problem. For some reason the error message that Salesforce is giving isn't the real error that's actually occurring. I looked through the logs for the specific error and it happened to be an error with our pricebooks. After fixing that everything else worked fine.


1

use this code, I have tested it and it is working fine in my org: trigger emailFollowers on FeedItem (after insert) { String OppKeyPrefix = Opportunity.sObjectType.getDescribe().getKeyPrefix(); for (FeedItem f: trigger.new) { String parentId = f.parentId; if (parentId.startsWith(OppKeyPrefix)) { Messaging.SingleEmailMessage mail =...


1

Create a custom field at Contract object "Opportunity Team Mail Address (API name: OpportTeam_Mail_Address__c )". Then with the help of below trigger on update of any contract, we will be able to tag the email address of the Account Team Member. Please find the Trigger below: trigger TagOppTeamMemEmailAddress on Contract (Before Update) { Map<Id,Id&...


1

Use the following query for to filter only active Team Members Select o.User.IsActive, o.UserId, o.OpportunityId, o.Id From OpportunityTeamMember o where o.User.IsActive=true You will have to just convert to dynamic query in your case


1

OpportunityTeamMember.OpportunityAccessLevel is not a writeable field. You will have to make use of Opportunity Share object to achieve this. Hence you need to use the below mentioned code to provide the access. OpportunityTeamMember oppTeam = new OpportunityTeamMember(); oppTeam.TeamMemberRole = 'Sales Manager'; oppTeam.UserId = uv.Owner.ManagerID; ...


1

Since OpportunityAccessLevel is a Restricted picklist. Valid values are: Read, Edit. For more details on Read Only is not supported error, refer [this][1] link.


1

tl;dr version: In my eyes, Cases are a more natural fit for a patient-care model. Opportunities could have been used, but it feels like that would require a lot of shoe-horning to make it work. long version: Besides the fact that Salesforce seems to provide additional objects (and supporting logic) for tracking visits as Cases, there are probably ...


1

You can clone the OpportunityTeamMember records and just change the OpportunityId if you want to move the team. You may also wish to delete the old records, it is unclear from your post. Something like: List<OpportunityTeamMembers> newTeam = new List<OpportunityTeamMember>(); for (OpportunityTeamMember member : existingMembers) { ...


1

As you say you've done a lot of customization, the impact of enabling Opportunity teams is something that's impossible for anyone here to advise you on. This is something that you'll want to test in a sandbox with data to see if it affects any of the customization you have in place. That's exactly what purpose of sandboxes are for. Opportunity teams are a ...


1

To Kieth's comment above, I was able to verify that the email of the user actually exists by adding the below debug to your code: system.debug('### mapOppId Email - ' + mapOppId_usrEmail.values()[0][0].user.email);


1

Update from Summer 14 From the release notes on Complete Customization Available for Opportunity Splits You can customize opportunity splits in these ways: - Set up validation rules - Set up triggers So you can now create a trigger that could use addError() onUpdate to prevent changes as required. Pre-Summer 14 I was going to suggest creating a ...


1

We have implemented a custom VisualForce page in the past that allows multiple users to add team members, therefore overriding the security need of having 1) Edit access and 2) Owner or above owner in hierarchy.


Only top voted, non community-wiki answers of a minimum length are eligible