I've been running into some issues with Process Builder and how it handles duplicate values. To be clear - this is not a question about duplicate contact records.
I have a Flow and a Process set up to automatically add users to a Case team - such as the case creator. Separately in Case Assignment rules, I have a default case team established for a specific Record Type.
The error I am getting is when a user who is on the default case team, also creates a case. This leads to a duplicate value error in the case team (assiged first in the assignment rule / default case team, and then attempts to update again with the Flow and Process builder) and the flow will not execute and no record is created.
Has anyone dealt with something similar ? Is there a way to prevent the whole process from failing (and thus a record not being created). It seems like there should be a way to handle the error a little less disruptively.
Currently having an issue with email-to-case and process builder.
We have one email-to-case address activated (support@example.com) This is set to create cases with a record type of 'Example - 1'
Separately I have a Process that handles some updates to case ownership. The criteria for those processes are as follows: case.recordtypeid.developername = 'Example - 2 ' or 'Example 3'
The thing I can't figure out it:
The email-to-case record type is excluded from the entry criteria for the process - but, everytime we get an email to the email-to-case address that process throws an error. So how is this record type (Example - 1) throwing an error in a process it is not part of ?
Trying to write a trigger to update the LastActivity Date on contacts related to a completed task. We have Shared Activities enabled and I would like to get a list of all related contact IDs from TaskWhoRelation.
This query works in Workbench - but in the DeveloperConsole I only get 1 contact Id returned (the primary contact): Select RelationID from TaskWhoRelations Where TaskID = ' xxxxxx'
There is a known issue with triggers on Shared Activities: https://success.salesforce.com/issues_view?id=a1p30000000Su0FAAS
So I guess this is just confirmation - but does anyone know if it is possible to get all the related contactIds from a task into a list ? Or is this just not possible.
I have a trigger that currently creates a chatter FeedItem and posts to the Parent record on certain conditions. Now I am being asked to also make sure any comments made on the FeedItem in the Child record are also posted to the duplicate post on the Parent record. (basically duplicating the comments and making sure they are posted in both places. ) The goal here is for people to be able to follow only parent records (let's say Accounts) - and receive all child record posts and comments under the Parent record.
I'm able to create the individual posts - but can't figure out how to map comments from the child record FeedItem to the correct Parent record FeedItem.
Since there are two FeedItemIDs (one on child, one on parent) how can I find the correct FeedItem Id on the parent record - assuming each Parent record has multiple feed items ?
Looking for some confirmation on this from the community. I have inherited an org with lots of outdated apex, and multiple changes to VRs, field requirements, field values, profile names, record type names etc. All of this was done without any insight into, or konwledge of, apex that had also been written many years ago.
Production code coverage is now hovering around 40%......
Most of the existing custom apex is now irrelevant (outdated processes that are no longer used) and I need to get coverage up so I can begin to push change sets and update the existing org.
Since my primary goal is to raise code coverage and then delete many of the existing classes, triggers, extensions, etc my question is: Can I simply replace existing class code with simpler classes and test classes rather than dig through and update the existing code and configuration?
Again, the goal is to get rid of a lot of this code anyway so this seems like a quick and dirty solution to an otherwise overwhelming problem.
Looking for a little direction to get my org cleaned up. I've inherited a few years worth of unmaintaned Apex and VF pages that are causing all kinds of problems - the most immediate of which is preventing me from deploying change sets.
I fixed a number of SOQL related errors for one specific change set, but I'm still unable to delpoy. Apparently my code coverage is only 66%. So my question is: Where do I even start looking to address the gap from 66% to 75% ?
Short term goal is simply to get a change set deployed. I know longer term we'll need a more comprehensive update to existing customizations.
The options I see are: - Get coverage up to 75% percent (unsure where to start here since I'm just getting a general error message - and no specific classes or triggers are called out) - Start deleting classes that are no longer relevant (scary because I'm unsure of what other issues this may cause....)
Any help, or general direction on how to start tackling this issue would be great. Thanks!
I'm trying to create an inline Visualforce page to substitute for the standard 'Name' related list on Shared Activities. The problem I am trying to solve is getting more information that just the related name and type (Lead or Contact) to display in the name related list on the task detail page.
I created a basic page using the code below, but it seems as though Task.WhoId only looks at the Primary Contact and not other related contacts.
Has anyone used TaskWhoIds to return a list of ALL related contacts/leads for shared activities ? And am I able to use TaskWhoIds to get the accountIds of other related contacts ? For Example <<Task.TaskWhoIds.AccountId>>
Looking for some confirmation on this from the community. I have inherited an org with lots of outdated apex, and multiple changes to VRs, field requirements, field values, profile names, record type names etc. All of this was done without any insight into, or konwledge of, apex that had also been written many years ago.
Production code coverage is now hovering around 40%......
Most of the existing custom apex is now irrelevant (outdated processes that are no longer used) and I need to get coverage up so I can begin to push change sets and update the existing org.
Since my primary goal is to raise code coverage and then delete many of the existing classes, triggers, extensions, etc my question is: Can I simply replace existing class code with simpler classes and test classes rather than dig through and update the existing code and configuration?
Again, the goal is to get rid of a lot of this code anyway so this seems like a quick and dirty solution to an otherwise overwhelming problem.
Looking for a little direction to get my org cleaned up. I've inherited a few years worth of unmaintaned Apex and VF pages that are causing all kinds of problems - the most immediate of which is preventing me from deploying change sets.
I fixed a number of SOQL related errors for one specific change set, but I'm still unable to delpoy. Apparently my code coverage is only 66%. So my question is: Where do I even start looking to address the gap from 66% to 75% ?
Short term goal is simply to get a change set deployed. I know longer term we'll need a more comprehensive update to existing customizations.
The options I see are: - Get coverage up to 75% percent (unsure where to start here since I'm just getting a general error message - and no specific classes or triggers are called out) - Start deleting classes that are no longer relevant (scary because I'm unsure of what other issues this may cause....)
Any help, or general direction on how to start tackling this issue would be great. Thanks!
