Salesforce Integration Intern

Sign up for a free Developer Edition org, which includes full API access at no cost.

Understand the model first.

Research how Salesforce authenticates API callers and write a short explanation of what a connected app is, what a client identifier and secret do, what an access token is, and why tokens expire.

Create a connected app in Setup, enabling OAuth with the scopes your work requires.

Deliberately grant the minimum scope rather than full access, and write why that matters.

Now authenticate.

Obtain an access token using an OAuth flow appropriate for a server-side caller, using any free HTTP client such as the browser, a command line tool, or a desktop API client.

Capture the request and the response with the token redacted.

Make your first call.

Query your own user record through the REST API and capture the response.

Then explore the API surface.

Call the endpoints that describe what is available, listing the objects in your org and describing one object's fields, and record what this tells you about building an integration without documentation.

Handle failure.

Deliberately call with an expired or invalid token, capture the error, and write how a production integration would detect and recover from this.

Finally, write the security note covering where a client secret must never be stored and why.

Submit the authentication explanation, connected app configuration with scope reasoning, the token exchange with evidence, your first query, the discovery calls, the failure case with recovery approach, and the security note.

Build a small data model in your org with at least two related objects and twenty records to work against.

Read first.

Use the REST API to query records with SOQL, retrieve a single record by its identifier, and retrieve a record with its related records.

Capture each request and response, and note how the response differs between them.

Handle paging.

Query more records than a single response returns, find the continuation marker, and retrieve the next page.

Write why an integration ignoring paging silently loses data, which is a common and hard-to-spot bug.

Now write.

Create a record through the API and confirm it appears in the org.

Update a field on an existing record.

Delete a record.

Capture each request, response, and the resulting state.

Then handle writes that fail.

Attempt to create a record violating a validation rule, missing a required field, and referencing a parent that does not exist.

Capture each error response and write what an integration should do in each case, distinguishing errors worth retrying from errors that will never succeed.

Work with batches.

Create several records in one call, then deliberately make one of them invalid and observe what happens to the others.

Record whether the call is all-or-nothing and how you would control that, because partial success is the hardest case in integration work.

Finally, use an external identifier to upsert, and explain why upsert matters when syncing with another system.

Submit all request and response captures, the paging work with its explanation, the write operations, the error cases with handling decisions, the batch partial failure findings, and the upsert work.

Integration runs in both directions, and calling out has constraints calling in does not.

Choose a free public API needing no payment or approval, such as a public postcode, currency, weather, or holiday service, and read its documentation.

Configure access.

Create the remote site or named credential entry permitting the callout, and write why Salesforce requires this registration.

Build the callout.

Use Apex or an external service in Flow to call the endpoint, parse the response, and store a useful value on a Salesforce record.

Capture the working result.

Now handle the unhappy paths, which is most of real integration work.

Force and handle each of the following: the endpoint returning an error status, the endpoint returning unexpected or malformed data, and the endpoint not responding.

Record what your code does in each case and make sure a failure never leaves a record half updated.

Respect the limits.

Research the callout limits in a transaction and what happens when a callout runs inside a trigger.

Write why callouts cannot be made from certain contexts and how asynchronous processing solves it, then implement the asynchronous version.

Test without the endpoint.

Write a unit test for your callout using a mock response, and explain why tests must never call a live external service.

Finally, write the operational note: how someone would know this integration broke, and what they would check first.

Submit the API choice and configuration, the working callout, the three failure cases with handling, the limits analysis with the async implementation, the mocked test, and the operational note.

This task is the design thinking that separates a working demo from an integration that survives production.

Define a realistic scenario: Salesforce and one external system needing to stay in step, such as a billing system, a website database, or an inventory list.

Design the synchronisation.

State which system owns each field, what triggers a sync in each direction, how often, and what happens when both systems change the same record before syncing.

This conflict case is the one most designs omit, and it is the one that corrupts data.

Choose the mechanism per direction, deciding between real-time callouts, scheduled batches, and platform events, and justify each choice against volume and how current the data must be.

Account for the limits.

Document the API call limits for your org, estimate the calls your design consumes per day at a stated volume, and show the calculation.

Then state what breaks first if volume multiplies tenfold, and how you would change the design.

Plan the failure handling.

For each failure mode, covering the external system being down, authentication expiring, a record failing validation, and a partial batch failure, state what happens, what retries, and what alerts a human.

Design the monitoring.

Specify what you would log per sync, how someone detects a silent failure where nothing errors but nothing syncs either, and how you would reconcile the two systems to prove they match.

Build the core of one direction in your org as proof, and record what the build revealed that the design had missed.

Submit the scenario, the sync design including the conflict rule, mechanism choices with justification, the limits calculation with the tenfold analysis, the failure handling plan, the monitoring and reconciliation design, and the proof build with findings.