Evaluate
Don't take our word for it. Test it on your portal.
Portal styling tools fail in three predictable places: selectors that break on the next release, merges that silently clobber existing CSS, and handoffs that arrive as loose snippets. OmniStyler was built around those failure points, so that is exactly where you should test it. Twenty minutes on your own portal beats any testimonial.
The twenty-minute evaluation
1. Selector stability
Pick a FlexCard or SLDS component, restyle it, then reload the portal and navigate away and back. The rule should still target the same surface, because it anchors on data-test-id, not on the class names Salesforce regenerates.
2. Merge behavior
Paste your portal's existing Head Markup CSS, merge your edits into it, and diff the result. Unrelated existing rules should survive untouched, and the conflict report should flag anything that still outranks your changes.
3. Review workflow
Duplicate a theme, mark it in review, add a note, and export the standalone preview. A stakeholder should be able to approve the design without Salesforce access or a screen-share.
4. Deployment handoff
Download the deploy kit and hand it to a developer cold. The static resource, metadata, head markup, and README commands should be enough to ship without a single follow-up question.
What a pass looks like
- Rules keep applying after reloads and normal Salesforce DOM churn.
- The merged stylesheet preserves every unrelated existing rule.
- A designer produces a client-ready preview without admin access.
- A developer deploys from the kit without asking what goes where.
- Draft, review, approved, and archived variants coexist on one portal without stepping on each other.
Ran the evaluation on a real project? Tell us how it went, especially where it fell short. Before/after stories we publish with explicit approval; rough edges we fix. Either way: [email protected].