0

We have a checkbox custom field on Account that defaults to false. It's part of a managed package that we provide. Because it is in a managed package, our customers who install the package can't change the default value themselves directly.

We'd like our customers to be able to change the default value of the field to true if they wish.

Is it possible to programatically change the checkbox field default value via Apex? Or to make the default value editable even though its in a managed package? Is there any other way to achieve this functionality?

Update: If possible, we'd like to avoid achieving this with a Trigger/Workflow Rule on Account creation, because it will look to the user on the New Account page like we are setting the field False but in fact it will be created as True.

2 Answers 2

2

I think there are more than few ways to achieve that goal... First of all you can make a simple WF Rule that on each create update the field = True. A Trigger can also be written if needed to set it as True and if you want to control when should the Trigger run in each Org you can add Custom Setting which can set the Criteria as you want..

3
  • Thanks Yuval. In both of these options, if a user is creating a new Account, they will see the checkbox as unticked on the New Account screen but then it will be ticked on create, right? This could be confusing for users so if I can have the checkbox set correctly on the New Account screen it would be ideal.
    – sheilak
    Jul 29, 2015 at 20:30
  • 1
    Well If you need it in Layout and not just the Value... I guess another approach can be to create a New field which is turn by default On and to WF field update your current field with the opposite Value which I guess you have some logic on it...
    – sfdx bomb
    Jul 29, 2015 at 21:11
  • Thanks, probably I'll go with simple WF or Trigger for now. I've also voted on this related idea on IdeaExchange
    – sheilak
    Jul 30, 2015 at 16:36
1

I just stumbled upon this old question and I wanted to add that I advise heavily against using workflows in managed packages. First of all - they can be disabled in the customer org. While this seems okay-ish for simple cases this can be hard to debug if you have some super important workflow that lot of other functionality depends on. But even worse - they are really buggy when it comes to multi-language packages so there are cases where you workflows suddenly stop working even though they are active.

What worked for me so far is the usage of a trigger that can be configured through e.g. custom settings or other means - that gives you the flexibility you need without all the issues that workflows bring.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .