Active Pages and Classes Checklist

Use this checklist to plan, build, share, and roll out an Active Page or Active Class end to end. Administrative steps live here; code-authoring steps link out to the Developer Guide.

Plan

☐ Define what the page or class does. Write one sentence describing the goal — for example, "Multi-step deal registration form for partners" or "Trigger that syncs Deal stage to an external CRM".

☐ Decide whether you need an Active Page, an Active Class, or both. Most user-facing flows need both: an Active Page for the UI and an Active Class as its Controller. Background logic and Triggers need only an Active Class.

☐ Pick the audience. Identify who needs access — specific Roles, a User Group segment, the Guest Role for unauthenticated visitors, or specific people.

Build — Active Class (if needed)

☐ Create the Active Class record Set Type, Label, Name, and Version, then open the IDE.

☐ Author the code in the IDE. Open the IDE directly at /sys/ide or via the Open in IDE button on the class's detail view. The IDE is the primary workspace for code authoring — the Setup record view only manages metadata. Use the Developer Guide for language reference, controller patterns, database APIs, and utility classes. Compile and save inside the IDE.

Build — Active Page (if needed)

☐ Create the Active Page record Set Type, Label, Name, and Version. Optionally attach a Controller (the Active Class you created above).

☐ Author the markup in the IDE. Open the IDE directly at /sys/ide or via the Open in IDE button on the page's detail view. (Creating from the Setup list does not auto-open the IDE; if you are already working inside the IDE, use its own new-page flow to stay there.) The Developer Guide documents the component library, layout, JavaScript utilities, and the MVC pattern.

☐ Add Mobile or Tablet variants if needed. The page's detail view exposes Mobile Content and Tablet Content slots. If left empty, the desktop Content is served on those device classes.

Share

☐ Configure sharing Add the Roles, User Groups, or specific people who should access the page or class. Use the Guest Role for content that should be visible to unauthenticated visitors and all logged-in users.

☐ If you embed the page in an Engagement Page, also confirm that the embedded Active Page widget's audience aligns with the Engagement Page's sharing.

Localize (Optional)

☐ Define Custom Labels for any user-facing text Replace hard-coded strings in your markup or code with Custom Label references so the same page or class can render in any enabled language. Worth doing up front if your portal serves multiple languages or may in the future.

☐ Add translations in the Translation Studio For every language enabled in Language Settings, add a translation for each Custom Label your page or class references. Untranslated labels fall back to the master Value.

Test

☐ Test as an administrator. Confirm the page renders, the Controller actions work, and the data path is correct.

☐ Test as an end user in each shared Role or User Group. Use Login As (or a test user account) to confirm visibility, navigation, and behavior match expectations.

☐ Test as a non-member. Use Login As for a user who should NOT have access. Confirm the page is hidden from navigation and direct URL access is denied.

☐ Test on Mobile and Tablet, if you have device-specific content variants.

Roll Out

☐ Add the page to navigation. If users will reach the page from a menu, add a Menu Item under Setup > Create > Navigation Menu.

☐ Communicate the change. If new functionality is being introduced, announce it before rollout.

☐ Schedule a review cadence. Active Pages and Classes that touch business logic deserve periodic regression testing as the platform evolves.

If You Run Into Issues

☐ Active Pages Troubleshooting Symptom-by-symptom resolutions for visibility, sharing, and embedded-widget issues.

<< About Active Classes | Creating and Managing Active Pages >>