Currently, roughly speaking we can define schemas that accesses the filter date range, during the SQL generation time, through FILTER_PARAMS.<CUBE_NAME>.<TIME_TYPE_FILTER_NAME>.filter(expression). This allows us to define subqueries filtered by the date range coming from a request. As in the following example:

  segments: {   
    fiveChatsExpert: {
      sql: `${expertId} IN (
        SELECT expert_id
        FROM ${CUBE} INNER JOIN ${Partners} ON ${partnerId} = ${Partners.id}
        WHERE ${FILTER_PARAMS.Partners.externalId.filter(`${Partners.externalId}`)}
        AND ${FILTER_PARAMS.ChatsStats.createdAt.filter(`${createdAtConverted}`)}
        GROUP BY 1
        HAVING count(expert_id) > 4
        )`,
    },
  }

When granularity is present in a coming request the final SELECT it's grouped by that granularity, as expected. However, if we want to use that grouping in a subquery, like the one in the example above, is not possible.
To see what this limitation affects, lets consider the query A, and the following cube:

cube('ChatsStats', {
  sql: 'select * from public.chats_stats',
  joins: {
    ...all joins well defined...
  }
  measures: {
  ...all measures well defined...
  }
  dimensions: {
  ...all dimensions well defined...
  }

  segments: {   
    fiveChatsExpert: {
      sql: `${expertId} IN (
        SELECT expert_id
        FROM ${CUBE} INNER JOIN ${Partners} ON ${partnerId} = ${Partners.id}
        WHERE ${FILTER_PARAMS.Partners.externalId.filter(`${Partners.externalId}`)}
        AND ${FILTER_PARAMS.ChatsStats.createdAt.filter(`${createdAtConverted}`)}
        GROUP BY 1
        HAVING count(expert_id) > 4
        )`,
    },
  }
});

Query A:
Give me the experts Id with 5 or more chats made from Partner X for this year
Chats Stats Expert Id by Chats Stats Five Chats Expert and Partners External Id = X and Chats Stats Created At this Year

Will generate,

SELECT
  "chats_stats".expert_id "chats_stats__expert_id"
FROM
  public.chats_stats AS "chats_stats"
  LEFT JOIN public.partners AS "partners" ON "chats_stats".partner_id = "partners".id
WHERE
  (
    "chats_stats".created_at >= $ 1 :: timestamptz
    AND "chats_stats".created_at <= $ 2 :: timestamptz
  )
  AND (
    "chats_stats".expert_id IN (
      SELECT
        expert_id
      FROM
        "chats_stats"
        INNER JOIN "partners" ON "chats_stats".partner_id = "partners".id
      WHERE
        "partners".external_id = $ 3
        AND (
          "chats_stats".created_at :: timestamptz AT TIME ZONE 'UTC'
        ) >= $ 4 :: timestamptz
        AND (
          "chats_stats".created_at :: timestamptz AT TIME ZONE 'UTC'
        ) <= $ 5 :: timestamptz
      GROUP BY
        1
      HAVING
        count(expert_id) > 4
    )
  )
  AND ("partners".external_id = $ 6)
GROUP BY
  1
ORDER BY
  1 ASC
LIMIT
  10000

which will return the correct output. But, if we add 'month' granularity as example, will generate the following SQL:

SELECT
  "chats_stats".expert_id "chats_stats__expert_id",
  date_trunc(
    'month',
    (
      "chats_stats".created_at :: timestamptz AT TIME ZONE 'UTC'
    )
  ) "chats_stats__created_at_month"
FROM
  public.chats_stats AS "chats_stats"
  LEFT JOIN public.partners AS "partners" ON "chats_stats".partner_id = "partners".id
WHERE
  (
    "chats_stats".created_at >= $ 1 :: timestamptz
    AND "chats_stats".created_at <= $ 2 :: timestamptz
  )
  AND (
    "chats_stats".expert_id IN (
      SELECT
        expert_id
      FROM
        "chats_stats"
        INNER JOIN "partners" ON "chats_stats".partner_id = "partners".id
      WHERE
        "partners".external_id = $ 3
        AND (
          "chats_stats".created_at :: timestamptz AT TIME ZONE 'UTC'
        ) >= $ 4 :: timestamptz
        AND (
          "chats_stats".created_at :: timestamptz AT TIME ZONE 'UTC'
        ) <= $ 5 :: timestamptz
      GROUP BY
        1
      HAVING
        count(expert_id) > 4
    )
  )
  AND ("partners".external_id = $ 6)
GROUP BY
  1,
  2
ORDER BY
  2 ASC
LIMIT
  10000

which will not answer correctly the query "Give me the experts Id with 5 or more chats made from Partner X for this year and grouped by Month".
In order to answer the aforementioned query correctly, it should be possible to write fiveChatsExpert segment in the following way:

    fiveChatsExpert: {
      sql: `(${expertId},  date_trunc(`${GRANULARITY}`, `${createdAtConverted}`) IN (
        SELECT expert_id, date_trunc(`${GRANULARITY}`, `${createdAtConverted}`)
        FROM ${CUBE} INNER JOIN ${Partners} ON ${partnerId} = ${Partners.id}
        WHERE ${FILTER_PARAMS.Partners.externalId.filter(`${Partners.externalId}`)}
        AND ${FILTER_PARAMS.ChatsStats.createdAt.filter(`${createdAtConverted}`)}
        GROUP BY 1, 2
        HAVING count(expert_id) > 4
        )`,
    },

so that the following SQL be generated,

SELECT
  "chats_stats".expert_id "chats_stats__expert_id",
  date_trunc(
    'month',
    (
      "chats_stats".created_at :: timestamptz AT TIME ZONE 'UTC'
    )
  ) "chats_stats__created_at_month"
FROM
  public.chats_stats AS "chats_stats"
  LEFT JOIN public.partners AS "partners" ON "chats_stats".partner_id = "partners".id
WHERE
  (
    "chats_stats".created_at >= $ 1 :: timestamptz
    AND "chats_stats".created_at <= $ 2 :: timestamptz
  )
  AND (
    ("chats_stats".expert_id,
    date_trunc('month',
     (
       "chats_stats".created_at :: timestamptz AT TIME ZONE 'UTC'
     )
  ) 
  IN (
      SELECT
        expert_id, 
        date_trunc('month',
          (
           "chats_stats".created_at :: timestamptz AT TIME ZONE 'UTC'
          )
         ) 
      FROM
        "chats_stats"
        INNER JOIN "partners" ON "chats_stats".partner_id = "partners".id
      WHERE
        "partners".external_id = $ 3
        AND (
          "chats_stats".created_at :: timestamptz AT TIME ZONE 'UTC'
        ) >= $ 4 :: timestamptz
        AND (
          "chats_stats".created_at :: timestamptz AT TIME ZONE 'UTC'
        ) <= $ 5 :: timestamptz
      GROUP BY
        1, 2
      HAVING
        count(expert_id) > 4
    )
  )
  AND ("partners".external_id = $ 6)
GROUP BY
  1,
  2
ORDER BY
  2 ASC
LIMIT
  10000

In this way, my suggestion is to have the granularity access through GRANULARITY context variables, or through FILTER_PARAMS.<CUBE_NAME>.<TIME_TYPE_FILTER_NAME>.granularity.

I believe that there are many other scenarios where access to granularity would be helpful.