WebService Method

Building a custom Apex WebService Method is straightforward syntactically but requires care around permissions, error handling, and testing. The four-step routine covers: declare the method with the webservice keyword and the right signature, grant Apex Class Access through profiles or permission sets, expose the WSDL to external integrators, and add test methods that cover the business logic. Each step has its own pitfalls; skipping any of them produces an integration that compiles in sandbox and breaks in production, usually around permissions.

1. 1
   Declare the WebService Method in a global class

   Create or open an Apex class with the global access modifier. Declare each method exposed as SOAP with global static return-type methodName(parameters) annotated with the webservice keyword between global and the return type. Use SOAP-compatible parameter types: primitives, sObjects, lists, or custom Apex classes whose members are also webservice. Document the method purpose, expected inputs, and outputs in a header comment so external integrators understand what they are calling. Add error handling: catch exceptions and rethrow them as meaningful SOAP faults with descriptive messages. The platform translates Apex exceptions to SOAP faults but the default messages are often unhelpful; explicit message handling is the safer pattern.

2. 2
   Grant Apex Class Access through profiles or permission sets

   In Salesforce Setup, open the profile or permission set used by the calling integration user. Add the containing Apex class to the Enabled Apex Class Access list. Without this grant, the WebService Method returns a permission error even when authentication succeeds. The grant is per-class, not per-method. Document the access grant in the integration runbook so future admins do not remove the permission set or profile when cleaning up unused configurations. For shared integration patterns (one Apex class containing methods called by multiple integrations), centralize the access in a single permission set that all relevant integration users carry.

3. 3
   Generate and share the Apex WSDL

   From Salesforce Setup, search Apex Classes, find the class containing the WebService Method, click WSDL. The platform generates a class-specific WSDL that describes the SOAP operations. Save the WSDL to a stable location and share it with the external integration team. They will use the WSDL to generate client stubs in their preferred language (Java, C#, Python, etc.). Document the WSDL version (the API version the class targets) so the external team knows which Salesforce release behavior to expect. Re-share the WSDL on every class signature change; old WSDLs reference old signatures and stubs generated from them stop working.

4. 4
   Add test methods that cover the business logic

   In a test class, write @isTest methods that call the WebService Method directly (no SOAP layer needed; just invoke the Apex method). Set up test data, exercise the method with realistic inputs, and assert the expected outcomes. Wrap async work in Test.startTest and Test.stopTest. Mock any external dependencies (HTTP callouts, custom settings) with the standard test mocking patterns. Aim for high coverage on the method itself plus at least one positive and one negative scenario. Add the test methods to your CI pipeline so any change to the WebService Method business logic gets validated automatically. Without tests, regressions in the SOAP integration ship to production undetected.