Public Groups in salesforce

public groups:

how to restrict one group users data to other group.

Ex:  group1 have 10 users and group2 have 10 users here group1 data is not visible to group2 and same like group2 also......

Make the organisation wide default (OWD) of that object to Private
when you make the OWD of a object to private only the owner and any one above directly in the role hierarchy will see the records of that object by default but for custom objects if you uncheck Grant Access Using Hierarchies next to the object then only the owner will see the records.

Now create a sharing rule where Records owned by Public Group1 is shared with Public Group1, that way any records owned by users in Public Group1 are visible to all users in Public Group1 but not to other users

                                                                                                                                           

Find Object and Field Permissions Through apex

                        Enforcing Object and Field Permissions

Schema.DescribeSObjectResult to verify whether the current user has read, create, or update access to an sObject, respectively. Similarly, Schema.DescribeFieldResult exposes these access control methods that you can call to check the current user's read, create, or update access for a field. In addition, you can call the isDeletable method provided by Schema.DescribeSObjectResult to check if the current user has permission to delete a specific sObject..

For example: you can call the isAccessible, isCreateable, or isUpdateable methods..

These are some examples of how to call the access control methods.

To check the field-level update permission of the contact's email field before updating it:

if (Schema.sObjectType.Contact.fields.Email.isUpdateable()) {

// Update contact phone number

    contact c = [select name,phone from contact limit 1];

    system.debug('before update pno' +c.phone );

    c.phone = '9393934143';

    update c;

    system.debug('update phone no' +c.phone);

}

 //To check the field-level create permission of the contact's email field before creating a new contact:

if (Schema.sObjectType.Contact.fields.Email.isCreateable()) {

// Create new contact

    contact cc = new contact(lastname = 'mathaji',phone = '7878787878');

    insert cc;

    contact co = [select name from contact where name = 'mathaji' limit 1];

    system.debug('new contact name ' +co.name);

   

}

//To check the field-level read permission of the contact's email field before querying for this field:

if (Schema.sObjectType.Contact.fields.Email.isAccessible()) {

Contact ccc = [SELECT Email FROM Contact limit 1];

    system.debug('email is accessible' +ccc.email);

}//To check the object-level permission for the contact before deleting the contact.

if (Schema.sObjectType.Contact.isDeletable()) {

// Delete contact

    delete[select name from contact limit 1];

}

Class Security:

1. From Setup, click Develop > Apex Classes.

2. Next to the name of the class that you want to restrict, click Security.

3. Select the profiles that you want to enable from the Available Profiles list and click Add, or select the profiles   that you want to disable from the Enabled Profiles list and click Remove.

4. Click Save.

To set Apex class security from a permission set:

1. From Setup, click Manage Users > Permission Sets.

2. Select a permission set.

3. Click Apex Class Access.

4. Click Edit.

5. Select the Apex classes that you want to enable from the Available Apex Classes list and click Add, or select the Apex

classes that you want to disable from the Enabled Apex Classes list and click Remove.

6. Click Save.

To set Apex class security from a profile:

1. From Setup, click Manage Users > Profiles.

2. Select a profile.

3. In the Apex Class Access page or related list, click Edit.

4. Select the Apex classes that you want to enable from the Available Apex Classes list and click Add, or select the Apex

classes that you want to disable from the Enabled Apex Classes list and click Remove.

5. Click Save.

                   

How to find Failure Records in Database.insert

Finding Error Records in database.insert

list<account> acc = new list<account>();
       acc.add(new account(name = 'mahi',phone = '090909'));
       acc.add(new account(name = 'mahit',phone = '0909090'));
       acc.add(new account(name = null));
       acc.add(new account(name = 'mahitf',phone = '09039090'));
       acc.add(new account(name = ''));
                                   
 database.SaveResult[] results = database.insert(acc,false);

    // Check results.
for (Integer i = 0; i < results.size(); i++) {
if (results[i].isSuccess()) {
System.debug('Successfully created ID: '+ results[i].getId());
} else {
System.debug('Error: could not create sobject '+ 'for array element ' + i + '.');
System.debug(' The error reported was: '+ results[i].getErrors()[0].getMessage() + '\n');
}
   
}

Overview of Security in Force.com

                           Profiles and Roles

                                  

1.     Every user in Salesforce has a profile. Profiles are of two types.

A.   Standard profile

B.    Custom profile

A user's profiles determines access to objects, and fields in objects.

2.     There are six type of standard profiles -

A.   Standard user

B.    System Administrator

C.    Contract Manager

D.   Marketing User

E.    Read Only

F.     Solution Manager

3.     Profiles control-

A.   The objects the user can access

B.    The fields of the object the user can access

C.    The tabs the user can access

D.   The apps the user can access

E.    The page layout that is assigned to the user

F.     The record types available to the user

4.     Standard profiles cannot be deleted. Access permissions to objects (and their fields) of standard profiles cannot be edited. Standard profiles have access to all standard objects. Read-only profile have read-only access to objects. However access to tabs and applications can be configured for standard profiles.

5.     Access permissions of Custom profiles can be edited. Custom Profiles are created by developers by cloning from a standard profile.

6.     For each profile one application has default status.

7.     Record Types are associated with profiles. Record type play two important roles in Salesforce -

A.   They help define values to be shown in picklist for different profiles.

B.    They are used to define a mapping between page layout and profiles. This ensures that different users are displayed different views of the same page, depending upon the layout template selected.

8.     A record is an instance of an object.

9.     Removing a field from page layout does not ensure that security of that field. The field may still be accessible using the API.

10. Security in Salesforce is defined at multiple levels. These levels are -

A.   Security at object level

B.    Security at field level

C.    Security at record level

                                                       i.            Organization-wide defaults

                                                     ii.            Role-hierarchy

                                                  iii.            Sharing rules

                                                   iv.            Manual Sharing

11. Object level security is given to profile level. Object level security is set up via Manage Users-->Profile section. Access for Read, Create, Edit & Delete can be set at standard and custom objects.

12. Field-level security is also applied at profile level. The field-level security is available via the "Set Field-level security" button in the field definition page. At field level, for each profile valid settings are Visible and Read-only.

When a user logs in the list of objects that are displayed to her is determined by object level security, and list of fields that are displayed to the user is determined by field level security settings of that profile.

13. The next set of security concepts work at record level. These constraints determine which records should be displayed to the users. The four constraints that determine record level access are - organization-wide defaults, role-hierarchy, sharing rules and manual sharing.

14. OWD stands for Organization wide defaults. This setting is defined at object level. OWD defined the default record level sharing for objects. All profiles get at least the privileges defined in OWD. OWD takes three different values -

A.   Private (Cant view and edit)

B.    Public Read only (Can view)

C.    Public Read-Write (Can view and edit)

15. Key concepts about Organization wide default -

1.     To find out what should be set as OWD for an object, first find out which user requires least access to an object. OWD is set based upon this users access requirement.

2.     Most restrictive record access is defined using OWD. Access to additional records is made available through Role hierarchy, Sharing rules, Manual sharing.

3.     We can set OWD settings for both Standard and Custom Objects.

4.     Changing OWD settings can delete Manual Sharing if that sharing is no longer needed.

5.     Public Read/Write is default OWD settings.

                        Role Hierarchy allows additional users access to records. A hierarchy of roles is defined based upon access requirements at record level. Each user belongs to a unique role. If a role has access to some record, than its parent and ancestors will also have access to this record. Roles can be created using the Manager Users menu. Roles are used to control record access, where as profiles are used to specify access at object and field level.

                        Public group used in a sharing rule. It is used to give access to folders. It consists of users, roles or "roles and subordinates". The default Public Group is “Entire Organization”. We cannot assign Public Groups to profiles.

                        Another related concept that Salesforce defines is Public group. Public group consists of users, roles or "roles and subordinates".

                        Sharing rule is defined using public groups. Record that match certain condition can be assigned to users in public groups using Sharing Rules. Sharing rules functionality is available via the menu Sharing Settings.

                        Manual Sharing is used to grant one-off access. Manual sharing can be granted by record owner, any one above the owner in role hierarchy and System Administrator. Manual sharing is used to handle exception cases where access to a particular record needs to be given to a specific user. There is a Sharing button on the records page. This is used to provide manual sharing. The Ownership of the record can be transferred to any user who has at least Read permission on the record.

                        If the Read permission for the object is revoked from the users profile, the user will not be able to see their own record.

                        Full access to the records means user can View, Edit, Transfer Ownership, Delete and Share the record. Full access is granted to:

o    Record Owner

o    Users above record owner in role hierarchy.

o    Users with “Modify All Data “ permission i.e. Admin

                        Apex Sharing Reasons can have upto 10 Apex Sharing Reasons. It can only be given for Custom Objects.

                           

Trigger.newmap and Trigger.oldmap in salesforce

                                             Trigger.newMap && Trigger.oldMap

• Trigger.newMap - A map of IDs to the new versions of the sObject records.Note that this map is only available in before update, after insert, and after update triggers.

• Trigger.oldMap - A map of IDs to the old versions of the sObject records.Note that this map is only available in update and delete triggers.

Trigger updatecontact on Account (before update,after delete) {
 
  if(trigger.isbefore && trigger.isupdate){
  map<id,account> mapcon = trigger.newmap;
  list<contact> cont = new list<contact>();
  list<contact> con = [select id,phone,accountid from contact where accountid in : mapcon.keyset()];
  for(contact c : con){
   c.phone = mapcon.get(c.accountid).phone;
   cont.add(c);

  }
  update cont;
}
  if(trigger.isafter && trigger.isdelete){
   map<id,account> delcon = trigger.oldmap;
   list<contact> ccc = [select id from contact where accountid in : delcon.keyset()];
   delete ccc;
 
 
  }
}
-----------------------------------------Test class--------------------------------------------------------
@isTest
public class testupdatecon {
    public static testmethod void main(){
        account a = new account(name = 'gopi',phone = '0000000000');
        insert a;
        contact c = new contact(lastname = 'love',phone = a.phone,accountid = a.id);
        insert c;
           
           
        account aa = [select id,name,phone,(select id,phone from contacts) from account where id =: c.AccountId];
        update aa;
        delete aa;
       
    }  
    }
                                   

Time Trigger in workflows

             Time based workflow

v  Can I have time based workflow on custom objects?

Yes, you can create time-based workflow rules on custom objects and any object currently supported by workflow.

v  What editions support time-based workflow?

Time-based workflow is available in EE, UE and DE editions.

v  What units of time are supported?

Currently only days and hours are supported.

v  Can I have my time-based workflow action count only business days?

Currently within standard functionality time-based workflow actions are based on over all days and cannot exclude weekends.

v  How does time-based workflow impact my existing records?

Workflow rules are not fired retroactively. In other words, if you create a rule now, the rules are not applied to previously created records. The same holds true for time-based workflow rules.

For example, when you create an opportunity reminder rule, it does not run against existing opportunities. The new rule only applies to records created or updated after the rule is activated.

v  What workflow actions can I use with time-based workflow?

All existing actions will be available for a time-based workflow rule: email alerts, field updates, tasks and outbound messages. Note that you will still not be able to create an email alert for a workflow rule on activities.

v  How do I create a time-based workflow?

The time-based workflow feature leverages the existing workflow engine. The actions for a workflow are now grouped into two sections: immediate actions and time-dependent actions. The basic rule configuration is the same, but for time-based rules, you configure time-triggers in the time-dependent actions section. Each time trigger can execute one or more workflow actions.

v  Can I configure multiple actions to occur at different points in time for the same rule?

Yes, you can create a time line of actions by configuring multiple time triggers and defining actions for each one.

For example, consider a rule for all high value opportunities (value > $500K, probability > 70%). The immediate actions could include sending an email alert to the account team stating that a new high value opportunity has been created. The time-dependent actions could include the following:

·         10 days before the opportunity, close date, assign a task to the opportunity owner to follow up with the customer.

·         7 days before opportunity close date, change the owner of the opportunity to VP Sales, and send an email alert to the new owner.

v  Are there any restrictions for time-based workflow?

You cannot configure time-dependent actions for workflow rules for which the evaluation criteria is set to "Every time a record is created or edited."

v  Can I see which time-dependent actions are pending execution?

Yes, all pending actions to be fired on a future date appear in the Workflow queue. System administrators can view and manage this queue through a new page in the Setup by navigating to Administration Setup -> Monitoring -> Monitor the Workflow Queue.

v  Will the pending actions in the queue ALWAYS fire?

No. Time-dependent actions remain in the workflow queue until processed or the rule criteria for the workflow rule is evaluated as false. If a record no longer matches the rule criteria when the rule is evaluated, Salesforce removes the time-dependent actions queued for that record.

For example, an opportunity workflow rule may specify:

·         A criteria set to "Opportunity: Status not equals to Closed Won, Closed Lost."

·         An associated time-dependent action with a time trigger set to seven days before the opportunity close date. If a record that matches the criteria is created on July 1st and the Close Date is set to July 30th, the time-dependent action is scheduled for July 23rd. However, if the opportunity is set to "Closed Won" or "Closed Lost" before July 23rd, the time-dependent action is automatically removed from the queue.

v  Can the pending actions for a record be queued again?

Yes, time-dependent actions can automatically be queued again if the record is updated and you set the evaluation criteria to be "When a record is created, or when a record is edited and did not previously meet the entry criteria." Using the previous example, if the opportunity status is changed from Closed Lost to Prospecting and the workflow rule evaluation criteria is set to "When a record is created, or when a record is edited and did not previously meet the entry criteria," Salesforce reevaluates the time triggers and adds the appropriate actions to the workflow queue.

v  What if the evaluation criteria is set to "Only when a record is created"

In this case, the workflow rule evaluates its time triggers only once. If the record that fired the rule changes to no longer meet the evaluation criteria, the pending actions are removed from the queue and the rule is never reapplied to the record. All pending actions are evaluated only for as long as the rule criteria is true. While Salesforce evaluates the rule every time the record is updated, it does not necessarily fire all the actions associated with the rule every time.

For example, consider two rules that are identical except the evaluation criteria of rule 1 is "On create only" and the evaluation criteria of rule 2 is set to "did not previously meet the rule criteria." If you create a record that matches both rules, Salesforce executes the immediate actions and queues the time-dependent actions of both rules. If you then update the record and it no longer meets the rule criteria, Salesforce removes the pending actions for both rules. Now, if you update the record so it once again meets the rule criteria, Salesforce only executes the actions associated with rule 2, which has an evaluation criteria set to "did not previously meet the rule criteria."

v  What happens if I update the value of a date field used in a time trigger?

If you update the date field used in a time trigger, Salesforce recalculates the time trigger as long as the time trigger has not yet fired and the recalculation does not reschedule the time trigger to a date in the past.

For example, if a workflow rule alerts the opportunity owner seven days before the opportunity close date and the close date is set to 2/20/2008, Salesforce sends the alert on 2/13/2008. If you update the close date to 2/10/2008 and the current date is 2/2/2008 or before, Salesforce reschedules the alert for 2/3/2008. The evaluation date of pending actions is ALWAYS reevaluated and updated if necessary irrespective of the rule criteria. Of course, if the rule is evaluated to false, it does not matter as the actions are removed from the queue.

v  What happens if I delete a record that has pending actions?

If you delete a record that has pending actions, the pending actions are deleted from the workflow queue and cannot be restored, even if you undelete the record.

v  Why do I get an error "pending workflow" when trying to convert a lead?

If there are any pending approval processes or workflow to be triggered, you will not be able to convert a lead.