When a client is committed to a vendor partly because of stakeholder relationships, your job as the evaluating consultant becomes more nuanced: you need to provide an accurate picture of what implementation actually involves so they can make an informed decision and scope the project correctly — not talk them out of the decision they've already leaned toward.

Here's an honest assessment of SailPoint Identity Security Cloud (ISC) on the three dimensions you're asking about.

Extending Connectivity: Reading and Writing Additional Attributes

SailPoint ISC uses a connector framework that has evolved significantly from the on-premises IdentityIQ connector model. The pre-built connectors cover the major enterprise applications (Workday, ServiceNow, Salesforce, Microsoft 365, and others), and for these, attribute mapping is handled through connector configuration rather than custom code.

Reading additional attributes beyond what the connector exposes by default generally requires modifying the connector configuration or, for attributes not natively exposed by the connector, writing custom rule code. SailPoint ISC uses BeanShell (a Java-based scripting language) for custom logic. Rule development requires someone comfortable with Java-style scripting and familiarity with SailPoint's object model — it's accessible to developers but not a no-code operation.

Writing attributes back to target systems is similarly connector-dependent. For native connectors with built-in write capabilities, attribute write-back is configurable. For write operations the native connector doesn't support, custom rules or the REST API connector (which can be configured to make arbitrary HTTP calls) are the typical approaches. The REST connector provides flexibility similar to a custom HTTP action — you can define the endpoint, headers, and payload — but it requires configuration and testing by someone familiar with the target system's API.

For non-standard applications without pre-built connectors, SailPoint ISC offers the Web Services connector (for REST/SOAP APIs) and the JDBC connector (for database-backed applications), plus SaaS Connectivity for writing custom connectors using the SailPoint connector SDK. Custom connector development requires Java development skills and is a significant investment relative to out-of-the-box connectivity.

The honest summary: extending connectivity in SailPoint ISC is feasible but involves code for anything beyond the default attribute set of supported connectors. Budget for connector development time in your scoping.

Extending the Data Model

SailPoint ISC's data model is centered on Identities, Entitlements, Access Profiles, and Roles. The model is well-suited to the IGA use cases it was designed for, and it can be extended in a few ways:

Identity Attributes can be extended through custom identity attributes, which are configurable in the admin UI. You can define new attributes, set data types, and configure whether they're editable and how they're populated. This is a no-code operation and is one of the more flexible parts of the configuration experience.

Application Schema Customization allows you to add custom attributes to the account schema for connected applications — useful when you need to track application-specific metadata that the standard schema doesn't capture. This is configuration-level work, not code.

Entitlement Attributes can be extended similarly to account schemas, allowing additional metadata on entitlements for more granular reporting and policy definition.

Governance Objects (Access Profiles, Roles) are assembled from entitlements and are the primary mechanism for modeling what access packages look like. Complex role hierarchies require thoughtful design work — not necessarily code, but significant configuration effort, particularly when role mining from an existing access landscape.

Where the data model gets constrained is in highly customized scenarios: if you need to model access in ways that don't map cleanly to ISC's identity/entitlement/role hierarchy, or if you need to relate governance data to external objects (projects, assets, organizational units beyond what ISC natively supports), you're working around the edges of the model rather than extending it natively. SailPoint's own reporting and workflow tools operate within the ISC data model, so edge cases here cascade into reporting and workflow complexity.

The honest summary: standard IGA data modeling is well-supported by ISC's configuration capabilities. Complex or non-standard data models require more creative approaches and potentially custom code.

Implementation: Where Code Is Actually Required

This is where SailPoint ISC evaluations most commonly produce surprises for clients. The marketing narrative emphasizes SaaS and reduced implementation complexity compared to on-premises IdentityIQ. The implementation reality is more nuanced.

Connectivity Setup

For applications with native ISC connectors and standard attribute sets: configuration-level work, no code required. This covers the majority of the initial connector setup for most clients with mainstream application estates.

For custom attribute reading/writing, non-standard connector configurations, and homegrown application integration: BeanShell rules or REST connector configuration. The REST connector is more configuration than code but requires developer familiarity to set up correctly for complex payloads.

Data Modeling

Identity attribute configuration, access profile and role creation: UI-driven, no code. Role mining analysis and design decisions: not code but significant consultant time. Complex certification scoping and correlation rules: BeanShell rules, which require scripting.

Screen Layouts and UI Customization

SailPoint ISC's user-facing interfaces (end-user access request UI, manager certification UI) are significantly less customizable than IdentityIQ's JSF-based front end. The end user interface is more standardized, which reduces customization burden but also limits UI customization for clients with specific UX requirements.

Security and Policies

Basic access policies, separation of duties rules, and certification configurations: UI-driven. Complex SoD rules with large entitlement scopes: performance and scoping work that may require guidance from SailPoint professional services. Policy exception handling with complex business logic: BeanShell rules.

Birthrights and Lifecycle Workflows

Standard lifecycle events (Joiner/Mover/Leaver) connected to HRMS triggers: configuration-level work once the HRMS integration is established. Complex conditional provisioning logic (different access packages based on multiple attributes or organizational exceptions): workflow rules in BeanShell.

The Professional Services Reality

Most SailPoint ISC implementations at enterprise scale involve SailPoint professional services or a certified implementation partner, and there's a reason for this: the BeanShell development, connector customization, and data model design work that makes up the non-trivial portion of an implementation requires SailPoint-specific expertise that most client IT teams don't have in-house.

Budget for an implementation partner if the client doesn't have internal SailPoint expertise. Timeline estimates of 6 to 9 months for a production-ready implementation covering the primary use cases (JML automation, access certifications, and meaningful role model) are realistic for a mid-to-large enterprise. Smaller, more focused implementations can be faster, but "smaller and more focused" often means the governance aspirations shrink to match the timeline.

The Comparison Question You're Implicitly Asking

You mentioned you have deep Omada experience but the client is committed to SailPoint due to stakeholder relationships. That's a common situation, and the honest framing for your client is:

SailPoint ISC is a capable, mature IGA platform. It will do what they need it to do. The questions are what it takes to get there and whether they have the organizational appetite and budget for the implementation. If they have a strong internal IT team with IGA experience (or budget for a good implementation partner), a realistic timeline, and governance requirements that fit within ISC's standard capabilities, it's a defensible choice.

If they're expecting a quick implementation with minimal custom development, or if their requirements include significant data model extensions or non-standard connectivity, the implementation complexity will exceed their expectations.

Your role as the evaluating consultant is to set accurate expectations on timeline, resourcing, and what "extended connectivity" and "data model customization" actually involve in practice — so that if they proceed, they proceed with accurate scope, and if they reconsider, they do so with full information rather than discovering the complexity mid-project.

Questions Worth Asking SailPoint During Evaluation

• For the specific applications in scope, which have native ISC connectors and which require the REST connector or custom SDK development? Get a connector-by-connector assessment.
• What is the current version of the certifications and workflow UI, and what customization is supported? The end user experience has varied significantly across ISC versions.
• For the role model they want to implement, how much role mining and design work is scoped in the professional services engagement?
• What is the recommended implementation partner for their region, and what does that partner's experience look like with clients of similar complexity?

The answers to these questions will quickly reveal whether the stakeholder relationships are leading the client toward a decision with accurate expectations or one that will surface surprises in month four of the implementation.