Product Documentation Clarity and Coverage

We've received feedback indicating that certain parts of the product documentation are difficult to understand, particularly when it comes to behavior that changes based on conditions on the CSP (Cloud Service Provider) side.

Specifically:

-There is limited documentation on how different configurations on the CSP side may affect product behavior.

-Security-related explanations are insufficient, making it difficult for users to assess whether a given configuration (e.g., permission boundaries, restrictions) will allow Cloudability to function as intended.

-For AWS, there is little clarity around how SCPs (Service Control Policies) might impact data collection or access.

-For Azure, explanations around role-based access control (RBAC) are fragmented or unclear.

-Additionally, the existence of two different connection methods in Azure leads to confusion, especially when the recommended method is not well documented under which circumstances.

We recommend enhancing the documentation with scenario-based guidance that clearly outlines:

-The minimum required permissions and configurations by CSP.

-How security constraints (like SCPs or custom roles) may interfere with expected functionality

-Decision trees or comparison tables that help clarify which connection method should be used in which case (e.g., Azure EA vs MCA, classic vs modern authentication, etc.)

This would greatly help customers in regulated industries or those with strict security postures who need clear and confident implementation paths.

In addition, we would like to request more clarity regarding how Cloudability behaves when certain policy checks fail in the vendor credential connection status screen.

Currently, when specific IAM policies or permission checks are marked with an “X” (indicating failure), it's unclear:

- Which specific Cloudability features are impacted

- What kind of limitations (e.g., partial data collection, missing reports, etc.) will occur as a result

- Whether this failure is critical/blocking or simply a warning with reduced functionality

For example, in AWS environments, if a particular permission is denied due to an SCP or IAM policy, we would like to know whether this affects:

-Savings Plan normalization

-RI utilization reporting

-CUR data ingestion

-Rightsizing recommendations

-Cost anomaly detection, etc.

A detailed mapping between each policy check and the associated functional impact would be invaluable, especially for enterprises operating under strict security policies. This would allow teams to prioritize which policy issues to resolve and understand the consequences of leaving specific permissions restricted.

We believe that documenting this linkage would significantly improve operational transparency and reduce troubleshooting time for our users.