Development Lifecycle and Deployment Designer : Exam Preparation Guide and Tips

First of all big thanks to everyone who follow my blogs and provide their valuable feedback. This motivates me to write something every month and share my knowledge by taking out time from so called busy professional life.

This is my 150th blog and have reached 500K pageviews with (500+ daily page views). Once again thanks to everyone!!

Along with this, I am really excited to get "System Architect" credential after completing "Development Lifecycle and Deployment Designer" Exam.

If you want to prepare about other exam for "System Architect" then refer below URL:

• SALESFORCE INTEGRATION ARCHITECTURE DESIGNER : Things to consider before appearing for this exam
• IDENTITY AND ACCESS MANAGEMENT DESIGNER : Exam Preparation Guide and Tips

Through this blog, I will be sharing some information which will help you to prepare for this exam.

As always, I started with trailmix Architect Journey: Development Lifecycle and Deployment designed for this exam. It has lot of information about different aspect for this exam.

Now I will specify different topics which will help you:

Migration Tools

• You should know the use case on when to use Change Sets, Force.com migration tool (ANT), force.com IDE.
• When you have separate release team for deployments, then being architect you need to make sure that all necessary components for deployment are specified in package.xml and associated metadata in .zip file to release management team.
• There are few exception which can not be migrated using Metadata API. So we have to deploy these components manually. Refer Unsupported Metadata List for deployments
• Custom setting can be migrated but custom setting data needs to be migrated manually after custom setting deployment.
• Prefer custom metadata types over custom settings if you want to migrated data during deployments.
• If you want to remove/delete certain metadata for clean up purpose, then create destructiveChanges.xml file and specify all components in that and then deploy using force.com migration tool. 

Sandbox Strategy

Salesforce offers sandboxes and a set of deployment tools, so you can:

• Isolate customization and development work from your production environment until you’re ready to deploy changes.
• Test changes against copies of your production data and users.
• Provide a training environment.
• Coordinate individual changes into one deployment to production.

Sandbox Types

• Developer Sandbox

A Developer sandbox is intended for development and testing in an isolated environment. Developer Sandbox includes a copy of your production org’s configuration (metadata).

• Developer Pro Sandbox

A Developer Pro sandbox is intended for development and testing in an isolated environment and can host larger data sets than a Developer sandbox. A Developer Pro sandbox includes a copy of your production org’s configuration (metadata). Use a Developer Pro sandbox to handle more development and quality assurance tasks and for integration testing or user training.

• Partial Copy Sandbox

A Partial Copy sandbox is intended to be used as a testing environment. This environment includes a copy of your production org’s configuration (metadata) and a sample of your production org’s data as defined by a sandbox template. Use a Partial Copy sandbox for quality assurance tasks such as user acceptance testing, integration testing, and training.

• Full Sandbox

A Full sandbox is intended to be used as a testing environment. Only Full sandboxes support performance testing, load testing, and staging. Full sandboxes are a replica of your production org, including all data, such as object records and attachments, and metadata. The length of the refresh interval makes it difficult to use Full sandboxes for development.

When you create a Full sandbox, you also have to decide how much field tracking history and Chatter activity to include.

• The default is to omit field tracking, but you can include up to 180 days of field tracking. If you track field history for many objects in your production org, specify fewer days to avoid generating an excessive amount of data.
• Chatter activity data can be extensive, which can add a significant amount of time to your Full sandbox copy.

Limit the amount of field history that you copy, and copy your Chatter data only if you need it for your testing use cases.

Sandbox Refresh Interval

• As a best practice, development and testing should not happen in same sandbox.
• If testing and development is happening in same org, then tester may face issues as development is going in same org.
•  Salesforce releases happen first in sandbox and then in production environment. So to identify if salesforce release will not impact your current development or features, test the functionality in preview sandbox (sandbox which is already upgraded to new release before production). 
• Salesforce sent notification about all instance or domain which are part of preview sandbox before every release. If your sandbox is not part of that, then raise request with salesforce to include your sandbox.

Continuous Integration

Continuous integration (CI) is a software development practice in which developers regularly integrate their code changes into a source code repository. To ensure that the new code does not introduce bugs, automated builds and tests run before or after developers check in their changes.

Using continuous integration, a product is built to include and integrate every code change on every commit (continuously), by any and all developers. An automated build then verifies each check-in, letting teams detect problems early.

Continuous integration (CI) is a component of the continuous delivery process that enables developers to integrate their updates into the master branch on a regular basis. With CI, automated tests run before and after each change is merged, validating that no bugs have been introduced.

• When you have multiple concurrent projects running along with new features, then always utilize the source control, build tool for deployment and automated test script.
• Continuous Integration Tools  includes Source Control Tool, Force.com Migration tool and sandbox environment where build can be validated and run automated test.
• Utilize unit and automated functional test script as part of continuous integration strategy.
• When multiple developers are working on different functionality along with bug fixes, then create separate branches for developers and merge their changes in common branch for testing.

Continuous Delivery

Continuous delivery ensures that code can be rapidly and safely deployed to production by manually pushing every change to a production-like environment. Since every change is automatically delivered to a staging environment, you can deploy the application to production with a push of a button when the time is right.

The additional step of pushing the code to a staging environment is what makes continuous integration different than continuous delivery. Having a green (successful) build with CI doesn't mean your code is production ready until you push it to a staging environment that matches the final production environment.

Continuous Deployment

Continuous deployment is the next step of continuous delivery. Using Continuous Deployment, every change that passes the automated tests is deployed to production automatically while continuous delivery is manual step.Most companies that aren’t bound by regulatory or other constraints should have a goal of continuous deployment.

While not every company can implement continuous deployment, most companies can implement continuous delivery. Continuous delivery gives you the confidence that your changes are serving value to your customers when you release your product, and that you can actually push that button anytime the business is ready for it.

Understanding Packages

A package is a container for something as small as an individual component or as large as a set of related apps. After creating a package, you can distribute it to other Salesforce users and organizations, including those outside your company.

• Understand the difference between manage and un-manage package.
• Manage package can be created in Developer edition and Partner Developer Edition.
• Aloha app is status given to manage package so that it won't count against limits imposed by SFDC. This is mainly utilized for Group and Professional editions.
• Unlock Packages 
• Unlocked packages help you add, edit, and remove metadata in your org in a trackable way so you can reuse components and upgrade your Salesforce apps easier and faster. They encapsulate all the metadata changes and updates you plan to make.
• These are especially suited for internal business apps.
• With an unlocked package, you have a lot of flexibility. Your admins can make changes directly in production in response to emergency change requests because metadata in unlocked packages can be modified in a production org.

Governance

If you have multiple teams working together and delivering different features at same time, then you need to establish governance to avoid technical debt on platform.  

Suppose each team is building different VF pages or installing different manage packages from appexchange, then their may be chances that developer are doing customization instead of referring salesforce standard capabilities. Also they spend additional effort on functionality which may be implemented by other team. Without governance, there are chances of multiple page layouts, duplicate fields or VF pages. 

• Center of excellence

This team can help to monitor if Salesforce development standards or practices have been followed or not and can also help in reducing the technical debt on platform. This team can emphasis on using Salesforce standard functionality instead on customization. This team can be involved in solution design reviews and can provide feedback before actual development.

• Change control board

Change control board can help in avoiding duplicates in system. This Committee makes decisions regarding whether or not proposed changes should be implemented. They can raise hand or point out if functionality is already existing in system. This committee can also help in monitoring the system limits and take decisions based on that.

Agile vs Waterfall Methodology

• Use agile approach if requirements keeps on changing based on end user feedback. This involves having DevOps for rapid testing and development. This is iterative approach in which we deliver features one by one. In this approach we estimate project time line and budget and will not have strict deadlines as requirements may vary based on end user feedback.
• Use waterfall methodology if project has fixed scope, timeline and budget. Also if requirements are pre-defined and end users are looking for complete product, then opt for waterfall.

Testing

• Load testing : This is considered as positive test as we monitor application performance with predefined load (concurrent operations).
• Performance testing: This test is performed to monitor response request time throughput and measuring mean time of application performance under normal conditions. This is also considered as positive test. For this we perform concurrent transaction to measure application performance.
• Stress testing : This is considered as negative testing. It is similar to load testing but we keep on increasing the load on application till application/server crashes down.
• Salesforce production is shared environment so stress testing is prohibited by salesforce. Salesforce impose lot of governor limits to avoid this.

Apex Hammer Test

Salesforce runs your org’s Apex tests in both the current and new release and compares the results to identify issues for you. The Hammer means taking every single Apex test that you or anyone else has created and running it twice.

Salesforce uses these results to identify any issues to resolve before the release.

Apex hammer test refer only those test classes which do not have access to org data.  The advantages of creating data silo tests are:

• Tests run more reliably because they aren’t dependent on data that can sometimes change.
• Failures from those tests are easier to diagnose.
• Finding bugs in the Hammer process is easier.
• Deploying from one org to another is more reliable.

Apex is not alone in running hammer tests.  Visualforce, packaging, Trialforce, and dashboards all go through a similar process.  The Apex process is the most involved, but the general principle of finding potential issues before you do is applied to all of these.

Hope this will help!!!

Best of luck for your exam!!!

IDENTITY AND ACCESS MANAGEMENT DESIGNER : Exam Preparation Guide and Tips

I am really excited to share that I have cleared "IDENTITY AND ACCESS MANAGEMENT DESIGNER" exam yesterday and going to share my inputs for people who are preparing for it.

I have successfully completed "Application Architect" credentials and if you would like to prepare for that then refer below links:

Data Architecture and Management Designer : Exam preparation guide and tips
Sharing and Visibility Designer : Exam preparation guide and tips

As usual I started with Resource Guide for Identity and Access Management designer exam. This time while preparing I gave more preference to Trailmix-Architect Journey: Identity and Access Management  specially to hand on training section.

This was really a tough exam for me as everything was theoretical as SSO is already configured in all companies. Also we won't get chance to work on identifying the identity provider and service provider configurations as my job roles mainly include to provide solutions to streamline business process. But anyhow is was mandatory exam in order to get "System Architect" credential, I started preparing for it just after clearing my "Salesforce Certified Integration Architecture Designer".

If you are preparing for Salesforce Certified Integration Architecture Designer exam then refer below link:
SALESFORCE INTEGRATION ARCHITECTURE DESIGNER : Things to consider before appearing for this exam

Below are the points which you should cover before appearing for exam:

My Domain

• My domain is required to configure SSO.
• Add a subdomain to your Salesforce org with the My Domain Salesforce Identity feature. If you specify login.salesforce.com as entity id in SSO, then identity provider will redirect to genric salesforce domain and salesforce again will open login page as it will not be able to understand on which subdomain user needs to be redirected. If you enable my domain and specify my domain in entity id, then redirection from identity provider will be easy.
• My domain is required for Single sign-on (SSO) with external identity providers, Social sign-on with authentication providers, such as Google and Facebook and lightning components in Lightning component tabs, Lightning pages, the Lightning App Builder, or standalone apps.
• You can rename your My Domain subdomain in production orgs. But you can't rename a sandbox, developer, or trial org subdomain.
• Authentication Configuration under My domain controls which all authentication services will be presented to user.
• If you want user to get authenticated from external identity provider then deselect login form from authentication services. 
• If login form is enabled as authentication services, then user may complain saying that they get redirected to salesforce login page instead of redirecting to identity provider login screen.

Salesforce 2 factor authentication 

• You can use out of box two factor authentication provided by salesforce. Create a permission set and assign “enable 2 factor authentication” permission in it. Now assign this permission set to user for which you want to enable 2 factor authentication. User needs to download Salesforce authenticator app and link their salesforce account. Now whenever user logged in, will get approve or reject option on salesforce authenticator. Salesforce authenticator will display device and location for log in and you can specify to remember that location so that next time you will not get notification when you log in. 

Custom Login Flow

• Login flows can be used to create custom 2 factor authentication.
• Refer Login Flows - Way to Customize User Authentication Flow for different use cases.

Salesforce OAuth Flows

• Refer Salesforce OAuth Flow - Implementation guidelines and tips  for complete understanding and their use cases.
• Given a scenario, you need to identify which flow to use.

Oauth Scope Parameter Values

• The scope parameter fine-tunes the permissions associated with the tokens that you’re requesting. Scope is a subset of values that you specified when defining the connected app.
• Different scope values are:
• api : Allows access to the current, logged-in user’s account using APIs, such as REST API and Bulk API. This value also includes chatter_api, which allows access to Chatter REST API resources.
• chatter_api : Allows access to Chatter REST API resources only.
• custom_permissions : Allows access to the custom permissions in an organization associated with the connected app, and shows whether the current user has each permission enabled.
• full : Allows access to all data accessible by the logged-in user, and encompasses all other scopes. full does not return a refresh token. You must explicitly request the refresh_token scope to get a refresh token.
• id : Allows access to the identity URL service. You can request profile, email, address, or phone, individually to get the same result as using id; they are all synonymous.
• openid : Allows access to the current, logged in user’s unique identifier for OpenID Connect apps. Use the openid scope in the OAuth 2.0 user-agent flow and the OAuth 2.0 web server authentication flow to receive a signed ID token conforming to the OpenID Connect specifications in addition to the access token.
• refresh_token : Allows a refresh token to be returned when you are eligible to receive one. Then the app can interact with the user’s data while the user is offline, and is synonymous with requesting offline_access.
• visualforce : Allows access to customer-created Visualforce pages. Doesn’t allow access to standard Salesforce UIs.
• web :   Allows the ability to use the access_token on the web, and includes visualforce, allowing access to customer-created Visualforce pages.

Identity License and External Identity License

• Identity license connects Salesforce users with external applications and services, while giving administrators control over authentication and authorization for these users.
• External Identity license is used for users outside of your organization’s user base (such as non-employees). Store and manage these users, choose how they authenticate (username/password, or Single Sign-On social sign-on through Facebook, Google+, LinkedIn, and others), and allow self-registration.

IDP-initiated or SP-initiated

• When salesforce act as service provider and identity provider is external app. If now user login by using my domain of salesforce, then it is called as SP initiated single sign on flow. In this case, salesforce will first redirect user to identity provider to get authorized and based on response from identity provider, will allow user to go to salesforce.
• If user login in identity provider and then redirect to service provide using some link, then it is called as IP initiated Single sign on flow.
• If you are using third party app as IP and salesforce and some external app are using third party as IDP. So if user click a link for salesforce resource on external app, then you need to configure SP initiated SSO that passes the SAML token to authentication provider when salesforce resource is requested.
• With an IdP-initiated login process, you typically set up a link on the company intranet that users click to get access to Salesforce. 

Identity Connect

• Identity Connect is a Salesforce Identity product that helps Salesforce admins apply all the data collected in AD to automate Salesforce user management. It syncs changes in AD within seconds.
• Identity Connect is on-premises software that sits behind your firewall and pushes data to Salesforce. Identity Connect’s server runs within the corporate network and communicates with the AD server over LDAP(S). It communicates with in-the-cloud Salesforce over HTTPS. Work with your networking engineer to ensure that these paths are open so that Identity Connect can connect to both AD and Salesforce.

• When Identity Connect detects differences between AD and Salesforce, it updates Salesforce with the information in AD. Data transfer is in one direction and AD is the source of truth. Identity Connect never changes information that's stored in AD.
• You can set up Identity Connect to manage multiple production orgs. And you can set up Identity Connect to manage multiple nonproduction orgs. But you can’t mix production and sandbox orgs in one Identity Connect environment.
• Different ways through which identity connect map AD Group user to Salesforce user are:
• Profile mapping with AD groups
• Permission set mapping with AD groups
• User role mapping with AD groups
• Salesforce groups to AD groups 

Self Registration - Communities

• Enable self-registration to allow unlicensed guest users to join your community. When your users self-register, you can choose to save them as contacts under a business account or create a person account for each self-registering user.
• If your business deals mostly with individuals, instead of creating them as contacts under a single business account, you can assign each self-registering user to a person account.
• If you want to create person account from self register page, then don’t specify account Id while creating account. You can also manually create person accounts and assign them to community users with Customer Community and Customer Community Plus licenses.

Canvas App

• Canvas enables you to easily integrate a third-party application in Salesforce. Canvas is a set of tools and JavaScript APIs that you can use to expose an application as a canvas app. This means you can take your new or existing applications and make them available to your users as part of their salesforce experience.
• The third-party app that you want to expose as a canvas app can be written in any language. The only requirement is that the app has a secure URL (HTTPS).
• Canvas app appearance in salesforce depends on the values you select in the locations field when creating the connected app in salesforce. 
• Canvas app can appear in chatter feed, Chatter tab, Console, navigation menu in salesforce app, VF page, Page layouts and mobile cards, Open CTI (in the call control tool), Chatter publisher and action bar.
• Force.com Canvas can use web Server OAuth Authentication Flow and User-Agent OAuth Authentication Flow.

Single Sign On Settings

• Configure single sign-on in order to authenticate users in salesforce.com from external environments
• With Just-in-Time provisioning, you can use a SAML assertion to create regular and portal users on the fly the first time they try to log in. This eliminates the need to create user accounts in advance. 
• Just-in-Time provisioning works with your SAML identity provider to pass the correct user information to Salesforce in a SAML 2.0 assertion attribute statement. You can both create and modify users, contacts, and accounts this way. Because Just-in-Time provisioning uses SAML to communicate, your organization must have SAML-based single sign-on enabled.
• To enable Just-in-Time provisioning, you must explicitly enable the checkbox in Single Sign-On Settings.

• Entity Id controls the redirection of user once it gets authorized by identity provider.
• If user is getting redirected always to home page after getting authenticated successfully, then it means identity provider is not able to preserve the relay state which specify where to redirect user after authentication.

Connected App

• A connected app integrates an application with Salesforce using APIs. Connected apps use standard SAML and OAuth protocols to authenticate, provide single sign-on, and provide tokens for use with Salesforce APIs. In addition to standard OAuth capabilities, connected apps allow Salesforce admins to set various security policies and have explicit control over who can use the corresponding apps.
• If you want your user to access salesforce using mobile devices and IP restriction is applied on user profiles, then if you relaxed IP restrictions for your OAuth-enabled connected app then user can access salesforce using mobile devices.
• IP relaxation does not apply to SAML-enabled connected apps unless they are also OAuth-enabled for single sign-on.
• Refresh Token Policy can also be set in connected app. If users are complaining that they need to login after some time on their mobile device, then check refresh token policy on connected app.
• Create connected app for external application to configure SSO for external application from salesforce. You can add profile and permission set to connected app to pre-authorize the user. Connected app is mainly used for inbound request to salesforce.

Federated Authentication

• Federated Authentication using SAML Federated authentication uses SAML, an industry standard for secure integrations. Investing in SAML with Salesforce.com can be leveraged with other products or services. If you use SAML, you don't have to expose an internal server to the Internet: the secure integration is done using the browser. In addition, Salesforce.com never handles any passwords used by your organization.
• When SAML is configured, the user (via their browser) hits either a URL at the enterprise Identity Provider (IdP) or, if My Domain is configured, any My Domain URL at Salesforce - e.g. https://mycompany.my.salesforce.com/SOMERECORDID. The SAML protocol redirects them for authentication in the enterprise, and sends them to Salesforce with a signed XML message representing that authentication.
• Signed XML request message contains federation Id to uniquely identify the user in salesforce.
• Salesforce user record Id, federation Id and username can be used to represent the identity of the user when Salesforce is acting as a Service Provider in a SAML configuration.
• User will face issues with SSO if federation Id is not specified in salesforce correctly which is being returned by identity provider.

Delegated Authentication

• Another option for authenticating users on Mobile and Desktop devices is Delegated Authentication. If enabled for an organization and user's profile, when a user attempts to authenticate directly to Salesforce, the credential is sent back to a customer configured endpoint over a HTTPS secured web-service.
• You need to request to salesforce in order to enable this feature.
• Salesforce uses the following process for authenticating users using delegated authentication:
• When a user tries to log in, Salesforce validates the username and checks the user’s profile settings.
• If the user’s profile has the Is Single Sign-On Enabled user permission, then Salesforce does not validate the username and password. Instead, a Web services call is made to the user’s organization, asking it to validate the username and password. Note Salesforce doesn't store, log, or view the password in any way. It is disposed of immediately once the process is complete.
• The Web services call passes the username, password, and IP address of the user to the customer's Web service. Your implementation of the Web service validates the passed information and returns either true or false.
• If the response is true, then the login process continues, a new session is generated, and the user proceeds to the application. If false is returned, then the user is informed that his or her username and password combination is invalid.
• Using this process, customers can easily use their existing authentication systems to validate credentials. This approach works will all mobile and desktop clients. Once a delegated authentication service is built and enabled for a user, there is no additional configuration required. Users will login using the regular Salesforce login screens, but their credential will simply be validated remotely.
• Salesforce sends the user request over SAML, but the request is sent back using delegated authentication. The RelayState parameter is transformed into the startURL parameter to redirect the user to the correct page. Using this technique, mobile and desktop clients that use SAML with Salesforce can also take advantage of SSO over delegated authentication.
• For security reasons, make your web service available by TLS. Webservice can be REST or SOAP.
• Delegated authentication offers the following benefits.
• Uses a stronger form of user authentication, such as integration with a secure identity provider.
• Makes your login page private and accessible only behind a corporate firewall
• Differentiates your org from all other companies that use Salesforce to reduce phishing attacks.

Federated Authentication vs Delegated Authentication

• Delegated authentication is inherently less secure than federated authentication. Even if encrypted, delegated authentication still sends the username and password (possibly even your network password) over the internet to Force.com. Some companies have policies that preclude a third party for handling their network passwords. 
• Delegated authentication requires much more work for the company implementing it. The Web services endpoint configured for the org must be developed, hosted, exposed on the Internet, and integrated with the company's identity store.
• Federated authentication happens through web browser and can not be used for mobile and desktop applications. Use federated authentication for mobile and desktop app.

Looking forward for everyone's comments and suggestion and best of luck for exam...

Hope this will help!!!

Salesforce OAuth Flow - Implementation guidelines and tips

Whenever an external app request to access salesforce data, authentication needs to be done on salesforce side. Different authentication flows are available as governed by OAuth standards.

Through this blog, i will share commonly used OAuth flows and factors which you need to consider while deciding which one to use.

OAuth 2.0 Web Server Authentication Flow

• This flow is mainly used by applications hosted on web server.
• If external application is trusted one and hosted on secure server and can securely store client_secret, then flow can be used.
• This flow is used mainly to build web application.
• First of all external application will request for access_token and user will be redirected to login page for authentication. After authentication, user will approve salesforce access by external app.
• After successful approval to grant access, authentication code will be returned through callback. External app will utilize this temporary OAuth token( valid for 10 mins) and send POST request to get access_token by sending temporary OAuth code, client_id and client_secret.
• Salesforce will return access_token and refresh_token. Refresh token can be used to regenerate the access token by external app so that user is not required to authenticate every time.
• Instead of sending client credentials as parameters in the body of the access token POST, Salesforce supports the HTTP Basic authentication scheme. This scheme's format requires the client_id and client_secret in the authentication header of the post as follows:         Authorization: Basic64Encode(client_id:secret)
• This flow is not recommended for application (like ETL or middleware's) which will access salesforce using API's and no UI is involved.

OAuth 2.0 User Agent Flow

• This flow is recommended when you build mobile or desktop application and your application can be distributed to anyone. So these kind of application are not considered as safe to store client secret because source code of application will be accessible to everyone and client secret can be exposed easily.
• This flow is used when external system application wants to login into salesforce using salesforce login credentials. Once user logged in, then he/she to approve that external application can fetch salesforce data(scope defined in connected app).
• In this flow, external application will pass only client id and user login page opens and user authenticate themselves to get access token, refresh tokens.
• External application can use use refresh token to get new access token if it get expired and can avoid logging user again in salesforce.
• With the user-agent authentication flow, the client app receives the access token as an HTTP redirection. The client app requests the authorization server to redirect the user-agent to another web server or to an accessible local resource. The server can extract the access token from the response and pass it to the client app. For security, the token response is provided as a hash (#) fragment on the URL. It prevents the token from being passed to the server or to any other servers in referral headers.

OAuth 2.0 JWT Bearer Token Flow

• Ideal for application which access sfdc only through API as there is no UI involved. For example ETL tools or middleware.
• A JSON Web Token (JWT) enables identity and security information to be shared across security domains. 
• JWT is basically a JSON file consisting of a header and claims object, where the header contains the signature algorithm and the claims object contains specific information such as the username and consumer key. At a high level, you will then sign the JSON object with the private key of your certificate and send the JWT to Salesforce to obtain an access token.
• When a client wants to use this flow, posts an access token request that includes a JWT to Salesforce’s OAuth token endpoint. Salesforce authenticates the authorized app through a digital signature that is applied to the JWT. 
• Digital certificates are required in this flow. Upload certificate (X509 ) to connected app which will be used to authenticate JSON web tokens.
• External application send request for access token by passing JWT token in body. SFDC server validate JWT and return access token to external app.
• No refresh token is returned in this flow. So if access token expires then send request to generate access token again.

OAuth 2.0 SAML Bearer Assertion Flow

• A SAML assertion is an XML security token issued by an identity provider and consumed by a service provider.
• The external app or client isn’t required to store client_secret.
• If you use active directory or LDAP as identity provider, then you will use SAML assertion from your SSO flow to obtain an access token to Salesforce.
• This flow used SAML assertion (XML token generated by Identity provide) and applied digital signature to it using certificates.
• In connected app, you upload this certificate (X509 ) containing private key. This key should be used while signing SAML asseration(base 64 encoded).
• The SAML assertion is posted to the OAuth token endpoint, which in turn processes the assertion and issues an access_token based on prior approval of the app(users are pre- authorized in connected app). 
• This flow also return only access token not refresh token

SAML Assertion Flow

• The SAML assertion flow is an alternative for Orgs that are currently using SAML to access Salesforce and want to access the web services API the same way. 
• You can use the SAML assertion flow only inside a single org.  So it means it can be used to connect to single sfdc org
• You don’t have to create a connected app to use this assertion flow. Clients can use this assertion flow to federate with the API using a SAML assertion, the same way they federate with Salesforce for web single sign-on.
• If you have SSO configured specifically for the Salesforce org that your partner application is authenticating to, you can also use the SAML Assertion Flow. 
• Configure SAML for your org. SAML version 2.0 is required. Exchange a SAML assertion for an access token. Use a JSON parser to process the response from salesforce to extract the access_token.
• The benefit of this flow is that you can use a Base-64 encoded, then URL encoded, SAML assertion that is normally used for web single sign-on. This makes it significantly more simple from a development perspective because you don't need to create a connected app but requires you to have SSO enabled for your Salesforce instance.
• No refresh token is issued in this flow.

OAuth 2.0 Username and Password Flow

• Use the username-password authentication flow to authenticate when the consumer already has the user’s credentials.
• Avoid using this flow because you have to send username and password un-encrypted to Salesforce.
• Use this flow only when there is no way to connect by using other available flows.
• Salesforce communities don’t support the OAuth 2.0 username-password authentication flow.
• In this flow, external app or client sends client_id,client_secret, username and password in POST request.
• The security token must be added to the end of the password to log in to Salesforce from an un-trusted network. Concatenate the password and token when passing the request for authentication.
• No refresh token is issued.

OAuth 2.0 Device Authentication Flow

• The OAuth 2.0 device authentication flow is typically used by applications on devices with limited input or display capabilities, such as TVs, appliances, or command-line applications. 
• This flow returns access_token and refresh_token.
• When device requests authorization by specifying client_id, Salesforce verifies the request and returns the following: human-readable user code, verification URL, device code, and minimum polling interval (in seconds).
• User navigate to verification URL and enters user code received.
• User prompted to login and approve access to salesforce data.
• In the meantime, the application running on the device should keep polling Salesforce (polling interval is also returned by Salesforce) and once the user has approved access, the application on the device will get an access token issued.
• After the access token is granted, the device can use it in API requests to access data on the user’s behalf. The device uses a refresh token to get a new access token if the access token becomes invalid.

OAuth 2.0 Asset Token Flow

• Client applications use the OAuth 2.0 asset token flow to request an asset token from Salesforce for connected devices. 
• In this flow, the device obtain an access token (in any of the above ways) and use this token alongside additional information to create an actor token. This token contains valuable information about the asset which is then send to Salesforce where it is exchanged for an asset token. Subsequent requests to protected resources at Salesforce can then be made with the asset token.
• In this flow, an OAuth access token and an actor token are exchanged for an asset token. This flow combines asset token issuance and asset registration for efficient token exchange and automatic linking of devices to Service Cloud Asset data.

OAuth 2.0 Refresh Token Flow

• The OAuth 2.0 refresh token flow renews tokens issued by the web server or user-agent flows.

Revoking Tokens

• Revoke an OAuth token if you don’t want the client app to access Salesforce data or if you don’t trust the client app to discontinue access on its own.
• When users request their data from within an external app (the consumer’s page), they’re authenticated. You can revoke their access tokens, or the refresh token and all related access tokens, using revocation. Developers can revoke the token when configuring a log-out button in their app.
• You can use POST method to revoke token as mentioned below

To revoke OAuth 2.0 tokens, use the revocation endpoint.
https://login.salesforce.com/services/oauth2/revoke 
Construct a POST request that includes the following parameters using the application/x-www-form-urlencoded format in the HTTP request entity-body. For example:
    POST /revoke HTTP/1.1
    Host: https://login.salesforce.com/services/oauth2/revoke 
    Content-Type: application/x-www-form-urlencoded
    token=currenttoken

• Salesforce also supports GET requests with the query string parameter token and the current token. If an access token is included, Salesforce invalidates it and revokes the token. If a refresh token is included, Salesforce revokes it and any associated access tokens. For example: 

https://login.salesforce.com/services/oauth2/revoke?token=currenttokenID

The authorization server indicates successful processing of the request by returning an HTTP status code 200. For all error conditions, status code 400 is used.

• If an access token is included, Salesforce invalidates it and revokes the token. If a refresh token is included, Salesforce revokes it and any associated access tokens.

You can also navigate to "Connected Apps OAuth Usage" under set up and block external app to create new sessions with connected app.

Hope this will help!!!

Login Flows - Way to Customize User Authentication Flow

Login flows acts as business process which you want to invoke for user after logging. Login flows are assigned at profile level.

How Login Flow works?

Custom 2 Factor Authentication

Login flows can be used to provide custom 2 factor authentication. Below is flow chart that I have prepared to implement this:

Different steps involved:

• Once user logged in, will be redirected to login flow.
• From login flow, call apex call which can either perform callout to external system which can send authentication code to user via SMS or email. You can use twilio app to send sms to users. You can store the auth code from callout response in salesforce(may be in some custom field on user object).
• If you don't want to use external app, then generate random code in apex and store it in custom field in user object and send email to user with code using apex email message methods.
• Once user receives the code will enter it in input text on login flow. 
• If user entered code matches with code stored in user object custom field then allow user to navigate to Salesforce. As a best practice clear the code stored in user object once validation completed so that user can not reuse the same code again.
• If there is mismatch, you can deny user access.

Important considerations while using login flows

• Login flow can not be used to replace Salesforce authentication but can used as additional set of authentication.
• Login flow can be used to display some important messages to users once they login. Refer Login Flows to Display Important Messages to User After Login to learn about this in detail.
• Login flows are only applicable for UI login not for API login.
• Login flow can be used with SAML JIT. If user doesn't exist then during JIT, first user will be provisioned and then login flow will kick off. If user fails 2 factor authentication from login flow,then deactivate the user again in salesforce.
• When user login, user login date like type of device, IP address, session id, user agent etc are available in visual workflow designer. This can be used to provide different user experience to user based on login device.
• As a best practice, do not enable custom 2 factor authentication for system administrators.

Hope this will help!!

Outbound Messages : Implementation Tips and Considerations

Outbound Messages are one way and asynchronous method to send some information from Salesforce to External systems. Best thing about Outbound messages is that it is declarative and no coding is required for this.

Outbound message follows "Remote Process Invocation—Fire and Forget" Integration pattern.

If you are planning to appear for "SALESFORCE CERTIFIED INTEGRATION ARCHITECTURE DESIGNER" exam then this blog will be helpful.

Below are implementation tips which need to know:

Reliable

• Outbound Message has in-built retry mechanism. 
• Messages will be queued locally. A separate background process performs the actual sending, to preserve message reliability
• If the endpoint is unavailable, messages will stay in the queue until sent successfully, or until they are 24 hours old. After 24 hours, messages are dropped from the queue.
• If a message cannot be delivered, the interval between retries increases exponentially, up to a maximum of two hours between retries.
• Messages are retried independent of their order in the queue. This may result in messages being delivered out of order.
• Source object may change after a notification is queued but before it is sent, so the endpoint will only receive the latest data, not any intermediate changes. Because a message may be delivered more than once, your listener client should check the notification IDs delivered in the notification before processing.

Security Considerations

• All Outbound messages are sent from Salesforce IP address. Make sure that Salesforce IP addresses are white listed in external system.
• Using SSL/TLS provides confidentiality while data is transported across the internet.
• You can pass user session Id in outbound messages so that external system can callback and update data back in salesforce.
• The organization Id is included in each message. Your client application should validate that messages contain your organization Id.

If your application (endpoint) server's SSL/TLS may be configured to require client certificates (two-way SSL/TLS), in order to validate the identity of the Salesforce server when it takes the role of client to your server. If this is the case, you can download the Salesforce client certificate from the Salesforce application user interface. This is the client certificate that Salesforce sends with each outbound message for authentication.

• From Setup, enter API in the Quick Find box, then select API.
• On the API WSDL page, click Manage API Client Certificate.
• On the Certificate and Key Management page, in the API Client Certificate section, click the API Client Certificate.
• On the Certificates page, click Download Certificate. The .crt file is saved in the download location specified in your browser.

Import the downloaded certificate into your application server, and configure your application server to request the client certificate. The application server then checks that the certificate used in the SSL/TLS handshake matches the one you downloaded.

How to prevent circular changes with outbound messaging?

It’s possible to create circular changes with outbound messaging. For example, user updates contact which trigger outbound message to external application. After this external application will update contact back in salesforce which can again trigger outbound message. To prevent these circular changes, you can disable a user’s ability to send outbound messages.

To disable outbound message notifications for a user, deselect Send Outbound Messages in the user’s Profile. 

We recommend specifying a single user to respond to outbound messages and disabling this user's ability to send outbound messages.

• Select Salesforce user while creating OM, to use when sending the message by specifying a username in the User to send as field. The chosen user controls data visibility for the message that is sent to the endpoint.
• Select Include Session ID if you want a sessionId to be included in the outbound message. Include the sessionId in your message if you intend to make API calls back to Salesforce from your listener. The sessionId represents the user defined in the previous step and not the user who triggered the workflow.
• The API Version for OM can only be modified by using the Metadata API not from UI.

Tracking Outbound Message Status

To track the status of an outbound message, from Setup, enter Outbound Messages in the Quick Find box, select Outbound Messages, and then click View Message Delivery Status. You can perform several tasks on this page.

• View the status of your outbound messages, including the total number of attempted deliveries.
• View the action that triggered the outbound message by clicking any workflow or approval process action ID.
• Click Retry to change the Next Attempt date to now. This action causes the message delivery to be immediately retried.
• Click Del to permanently remove the outbound message from the queue.

Capabilities of Outbound Messages

• Message can be delivered in out of order fashion as it is asynchronous process.
• Outbound Messages uses SOAP based calls. It can not be used for system which doesn't support SOAP API's.
• Organization Id is passed in all messages. 
• Session Id can be passed to implement 2 way communication by performing callback to Salesforce from external system

If you want to learn about Integration patterns then refer below blogs:

Integration Patterns and Best Practices for Salesforce - Part 1

Integration Patterns and Best Practices for Salesforce - Part 2

Hope this will help!!

Data Architecture and Management Designer : Things to consider before appearing for this exam

Today is very special day for me as I have completed my Application Architect exam by completing second exam (Data Architecture and Management Designer) on Architect journey and this is my 100th blog on Salesforce.

I would like say big thanks to Salesforce community who motivated for this and provided their support to achieve this.

Through this blog, I am going share my preparation experience and tips for everyone who all are planning for this.

• For self study, please refer Resource Guide for Data architecture and management designer, which contains all the study material links for different topics. If you complete this, then you are ready for this exam. 
• Development knowledge is not necessary for this exam but if you have development experience then you can easily understand Large Data Volume considerations easily.
• Exam contains lot of scenario based question. Most of question are like which decision or step you will take for given problem being Data Architect.
• Different ways of maintaining data quality.

Below are different topics which you need to cover for exam. Also I have accumulated below information from different source in place for quick overview.

• Duplicate Management

Please go through matching rules and Duplicate rules and how to configure them

Different option which you configure when duplicate detected(Alert, Block, reporting etc)

• Data Archiving and Purging

There were many question on for specific scenarios how to implement data archiving. Also cover on which case, we should use ETL tools.

Different points to remember:

1. Aggregate info on parent object and delete child object if reporting is required only in parent info.
2. Always plan for data archiving and purging as data keeps on increasing with time.
3. Records in recycle bin also affects query performance so if you don't want records, then perform hard delete.

• MDM Solution

When you have different application and different data stored in different application for customers, then implement MDM solution to have single source of truth for records. 

• PK Chunking

You can use PK Chunking with most standard objects and all custom objects.

To enable the feature you specify the header ‘Sforce-Enable-PKChunking‘ on the job request for your Bulk API query.

                           Sforce-Enable-PKChunking: 

By default the Bulk API will split the query into 100,000 record chunks – you can use the ‘chunkSize‘header field to configure smaller chunks or larger ones up to 250,000. Larger chunk sizes will use up fewer Bulk API batches, but may not perform as well. For each object you are extracting, you might need to experiment a bit to determine the optimal chunk size.

                       Sforce-Enable-PKChunking: chunkSize=250000;

You can perform filtering while using PK Chunking by simply including a WHERE clause in the Bulk API query. In this case, there may be fewer records returned for a chunk than the number you have specified in ‘chunkSize‘. 

If an object is supported, you can also use PK Chunking to query the object’s sharing table. In this case, determining the chunks is more efficient if the boundaries are defined on the parent object record IDs, rather than the share table record IDs. To take advantage of this, you should set the value of the Parent header field to the name of the parent object. For example, when querying OpportunityShare, set Parent to Opportunity.

For example:

Customer is planning a security audit and wants to identify all the manual shares that exist on their Account records. To execute this, they can perform a bulk query on AccountShare, using the filter WHERE rowCause=Manual, with a header like this: 

                   Sforce-Enable-PKChunking: chunkSize=250000; parent=Account 

• Data Governance & Data Stewardship

Data governance includes what type of information is required, who can create it and update it and specify quality rules(data  integrity, usability and security)

Data Stewardship includes how to maintain data and its distribution to its users.

• Skinny Tables

You can refer this blog for Skinny Tables Overview

• Bulk API

Cover different scenario on when to use parallel mode or serial mode for Bulk API.

If you are getting lock contention errors, then load child records order by parent record Id.

If you getting group membership locks, then use serial mode for Bulk API.

Lock contention errors may occur if you have master detail, lookup relationship and roll up summary fields defined.

Avoid full relaod operations as it will consume more resource. Try to perform incremental upload.

Please refer LDV Best practices link. It covers most of the topics for this exam.

Problem Statements

Slow report on a large object 

• Document your org’s indexed fields.
• Learn index selectivity rules.
• Build reports that use indexes.
• Don’t use formula fields (returning non-deterministic values) in filter as they are calculated on fly which will reduced the performance

 

Slow bulk data load 

• Cleanse and transform data pre-load.
• Disable triggers, validations, assignment rules,and workflow rules pre-load.
• Use the Bulk API.
• Keep a Full Queue : The Force.com platform cannot process what it doesn’t have the opportunity to process, and slowly feeding batches and jobs to Salesforce causes platform threads to sit idle when they could be processing batches. Always try to keep at least 20 batches on the queue at any given time. 

Lock contention problems while data load

• Pre-sorting the child records by parent Id in CSV file to lessen the chance of parent record lock contention among parallel load batches
• By deferring the org’s sharing calculations until data load finish, could significantly increase both the load and sharing calculation performance.
• For optional lookup fields, you can avoid the locks by setting the Clear the value of this field option, which does more than just tell Salesforce what to do if your lookup record is deleted. When you set this option, whenever a record that has a lookup field to this lookup record is inserted or updated, Salesforce doesn't lock the lookup records; instead it only validates that the lookup values exist.
• Roll Up Summary Fields : Salesforce locks those master records so it can update the appropriate roll-up summary field values. If detail records that look up to the same master record are updated simultaneously in separate batches, and those updates affect roll-up summary fields on the master record, there is a high risk that these updates will cause lock exceptions.
• Disable triggers and Workflow rules to improve performance. Whenever trigger perform DML on other records of object then salesforce lock those records which may cause lock contention errors in parallel load. When workflow update fields then it lock the records which can result in lock contention errors.
• Group Membership Locks: For a few special operations, Salesforce uses organization-wide group membership locks. To avoid lock exceptions when performing the following operations, you must use serial processing for your data load. 

1. Adding users who are assigned to roles 
2. Changing users’ roles 
3. Adding a role to the role hierarchy or a territory to the territory hierarchy 
4. Changing the structure of the role hierarchy or the territory hierarchy 
5. Adding or removing members from public or personal groups, roles, territories, or queues 
6. Changing the owner of an account that has at least one community role or portal role associated with it to a new owner who is assigned to a different role than the original owner

Full Database Backups are Slow

• Perform incremental data backups–only backing up the data that is new or updated since the previous incremental backup. When doing this, use queries that filter records using SystemModstamp (a standard field in all objects that has an index) rather than LastModifiedDate field (not indexed).

When to use serial load option rather than parallel?

• When you insert group members or users who are assigned to roles—or perform any other data load that requires group membership operations—Salesforce uses organization-wide group membership locks to ensure data integrity and security.
• If you are not able to manage or avoid lock contention errors then switch to serial mode for data load.

What are Strategies for Addressing Lags in Search Indexing?

Depending on the current load and utilization of indexing servers, asynchronous text index updates may lag behind actual transactions. This lag means that stale search indexes can lead to search results not entirely representative of the current database records.

The amount of time necessary to update search indexes is directly related to the amount of text data that such loads modify, and can be quite lengthy in some cases.

So how can you architect acceptable solutions that address inevitable lags in search indexing after data loads? Here are a couple of things to consider.

1. Disable full-text search indexing for custom objects (especially large ones) that don’t need to be searchable. 
2. Instead of relying on the full-text search engine and SOSL, implement your application’s search feature using SOQL. Because SOQL queries target the transactional database, they’ll always return results that correspond to the latest set of committed records.

Hope this will help!!!